• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Транзакции в Лотусе

  • Автор темы AlexeyStaf
  • Дата начала
A

AlexeyStaf

Добрый день!
Подскажите кто как решает вопрос по реализации транзакционной записи в БД. В большей степени интересует работа через C API, но можно и к LotusScript. Если будут какие-то готовые решения, то вообще замечательно :)
При создании документов мне видится пока один вариант: отдельно вести список созданных документов, при завершении транзакции очищать этот список. Если транзакция не завершена, то считывать из списка все доки и удалять их из БД.
С изменениями полей посложнее будет, т.к. надо хранить предыдущие значения. И при откате транзакции может возникнуть ситуация, что мне надо восстановить поле, которое после меня уже кто-то изменил...
Буду рад любым идеям :)
 
K

Klido

Что за откат транзакции?
Что для Вас вообще Транзакция в лотусе? :)
 
A

AlexeyStaf

Что за откат транзакции?
Что для Вас вообще Транзакция в лотусе? ;)
Мне необходимо произвести запись/изменение нескольких документов. Причем если на каком-то этапе возникла ошибка (отвалился от сервера по таймауту, сеть пропала или еще чего хуже сама программа записи дала сбой), то все действия необходимо отменить. В общем определение прям как для релиционных СУБД, но сделать это надо для Лотуса. Почему - вопрос отдельный :)
 
K

Klido

то все действия необходимо отменить
сочувствую....
софтина походу внешняя? ну так и пишите транзакции какие надо куда угодно+данные про лотусиный док (UNID и пр. что надо)... по необходимости - набор обратных операций... но чуднО - всё равно..
 
A

AlexeyStaf

сочувствую....
софтина походу внешняя? ну так и пишите транзакции какие надо куда угодно+данные про лотусиный док (UNID и пр. что надо)... по необходимости - набор обратных операций... но чуднО - всё равно..
Да, внешняя. Я и просил желательно применительно к Lotus C API. Я думаю, что не я один такой, кто с этим столкнулся - надеялся на может уже есть готовые наработки для этого.
 
K

Klido

желательно применительно к Lotus C API
нет разницы тут API или там OLE/COM... надо откатить действия - их надо залогировать согласно алгоритму внешней софтины...
Я думаю, что не я один такой, кто с этим столкнулся
боюсь вряд ли есть что-то толковое...
идеология лотуса особо не подразумевает таких манипуляций...ибо
что мне надо восстановить поле, которое после меня уже кто-то изменил...
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
178
в простом случае - сохранение всех меняемых доков в ДХЛ, до транзакции, в случае отката - импорт из негоже (с реплейсом текущих)
 
K

Klido

ну нам же надо знать как обычно:
- создание (тут для отката просто список UNID-ов и потом удалить по списку)
- удаление (тут для отката слив в DXL и потом залить)
- изменение (тут для отката слив в DXL перед изменением, а потом надо проверять не успел ли поменяться, а если успел - значит принимать какие-то решения)

это для простого случая, но, например, не просто создать, а ещё воркфлоу применить - там и почта полетит и пр.
 
A

AlexeyStaf

ну нам же надо знать как обычно:
- создание (тут для отката просто список UNID-ов и потом удалить по списку)
- удаление (тут для отката слив в DXL и потом залить)
- изменение (тут для отката слив в DXL перед изменением, а потом надо проверять не успел ли поменяться, а если успел - значит принимать какие-то решения)

это для простого случая, но, например, не просто создать, а ещё воркфлоу применить - там и почта полетит и пр.
Одно только беспокоит не сильно ли ударит по производительности экспорт в DXL? Благо удаления документов не предвидится. Но тем не менее запись полей периодически будет весьма оживленная.
 
T

turumbay

блокировки могут помочь. суть способа - сохранять изменения одновременно и как можно позже.
перед изменением документа лочим его, добавляем в коллекцию( класс - обертка, поддерживающая хранение доков из разных БД )
commit - сохранение коллекции, разлочка
rollback - просто разлочка.
это конечно не классическая транзакция, но бОльшая часть проблем у меня решилась.
блокировка заодно решает проблему, связанную с доступом: когда в процессе сохранения коллекции выясняеца, что у юзера нет прав сохранить предпоследний документ...
Прямое попадания баллистической ракеты в серверную такая схема конечно не переживет - т.е. от аппаратных/сетевых сбоев в момент сохранения защиты нету, но для обычных задач мне хватало.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
turumbay
я вот пытаюсь вас понять и не могу
неужели лотус изменил меня настолько что логика процедур, которые я пишу каждый день уже не должна содержать в себе откат транзакций...
Что мешает строить свои изменения таким образом, чтобы они продолжались с прерванного места?
И что плохого что часть данных будет уже новой? уж лучше часть чем вообще ничего
 
N

nvyush

И что плохого что часть данных будет уже новой? уж лучше часть чем вообще ничего
Что плохого, что со счёта покупателя средства списались, а на счёт продавца не поступили? Хотя, конечно, писать на Лотусе банковские и т.п. системы — маразм.
 
K

Klido

со счёта покупателя средства списались, а на счёт продавца не поступили?
хм... списали - создали док СПИСАНИЕ, ждем пока не поступят средства - создали док ПОСТУПЛЕНИЕ (как ответ списанию, например)...
если поступления не произошло - док СПИСАНИЕ помечаем неактуальным и заново... не вижу тут никаких откатов транзакций...

писать на Лотусе банковские и т.п. системы — маразм.
:(
 
T

turumbay

вообще, транзакции - отличная тема для пятничного флейма. скользкая, неочевидная, с кучей "а вот если так, то..."
если поступления не произошло - док СПИСАНИЕ помечаем неактуальным и заново... не вижу тут никаких откатов транзакций...
а пока поступления нет - считаем списание актуальным??? :) принцип двойной записи никто не отменял.
я выписал клиенту накладную: запасы уменьшились, дебиторка выросла. И меня не устроит, что товар уже списался, а баланс клиента еще не изменился. Если это произошло - система находится в некорректном состоянии. То, что систему переодически можно проверять на целостность - проблему смягчает, но не решает.

речь о том, что бывает ситуация, когда нужно изменить два документа одновременно, в рамках одной "транзакции". И домино не предоставляет этого функционала. Чтоб ни накручивали - всегда в результате будет два последовательных вызова doc.save. И нет возможность обеспечить атомарность такой операции.Т.е. проблема - системная. Ее можно всячески смягчать( блокировки, доп. проверки и т.п. ), но чистого решения нет.
И что плохого что часть данных будет уже новой? уж лучше часть чем вообще ничего
это верно, мягко говоря, не всегда.
 
M

Mikle0x

Имхо, по большому счёту надо писать серверную задачу для домины, которая будет перехватывать обращения к документам и реализовывать "промежуточный слой" с возможностью откатить операции, при желании. Аппаратные сбои должен обрабатывать лотусовый журнал транзакций.
Но это сложно, имхо на энтузиазме даже тех.задание нормальное не получится :sorry:
 
K

Klido

нужно изменить два документа одновременно, в рамках одной "транзакции". И домино не предоставляет этого функционала
Пт - не догоняю что именно вы там делаете :sorry:
если в пределах домино - тут и так все ясно..
Речь идет о некоей внешней софтине, которая по каким-то своим событиям дергает лотус... А тут атомарность транзакции размыта: есть транзакция внешней софтины, есть транзакция коммуникации с лотусом, есть транзакция действия в лотусе... Не вижу что может помешать в рамках одной внешней транзакции выполнить N транзакций в лотусе.
Внешние транзакции вообще тупо ставят некий признак в доках лотуса (у меня так с 1С - там проводки, отправки в клиент-банк, прием выписок банка и пр.), а лотусина уже обрабатывает признаки как её надо...

Как по мне - тема явно из-за попыток лотус заставить делать реляционные дела (с соответствующим подходом)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!