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

[AlexeyStaf]

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

 

[Klido]

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

 

[AlexeyStaf]

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

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

 

[Klido]

то все действия необходимо отменить

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

 

[AlexeyStaf]

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

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

 

[Klido]

желательно применительно к Lotus C API

нет разницы тут API или там OLE/COM... надо откатить действия - их надо залогировать согласно алгоритму внешней софтины...

Я думаю, что не я один такой, кто с этим столкнулся

боюсь вряд ли есть что-то толковое...
идеология лотуса особо не подразумевает таких манипуляций...ибо

что мне надо восстановить поле, которое после меня уже кто-то изменил...

 

[lmike]

в простом случае - сохранение всех меняемых доков в ДХЛ, до транзакции, в случае отката - импорт из негоже (с реплейсом текущих)

 

[Klido]

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

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

 

[AlexeyStaf]

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

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

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

 

[turumbay]

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

 

[ToxaRat]

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

 

[nvyush]

И что плохого что часть данных будет уже новой? уж лучше часть чем вообще ничего

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

 

[Klido]

со счёта покупателя средства списались, а на счёт продавца не поступили?

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

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

 

[turumbay]

вообще, транзакции - отличная тема для пятничного флейма. скользкая, неочевидная, с кучей "а вот если так, то..."

если поступления не произошло - док СПИСАНИЕ помечаем неактуальным и заново... не вижу тут никаких откатов транзакций...

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

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

И что плохого что часть данных будет уже новой? уж лучше часть чем вообще ничего

это верно, мягко говоря, не всегда.

 

[Mikle0x]

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

 

[Klido]

нужно изменить два документа одновременно, в рамках одной "транзакции". И домино не предоставляет этого функционала

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

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