Транзакция

[Medevic]

Привет всем !
Есть база
В ней есть основные документы. У этих основных документов есть документы-ответы (т.е. response). Эти документы-ответы могут меняться из основного документа как из встроенного представления так и через различные действия (события, кнопки и все такое).
Вот нужен механизм транзакций. После долгих раздумий было решено сделать так:
1) По кнопке (например, редактирования) основного документа создать локальную базу, в ней представление и скопировать туда ответы.
2) Произвести изменения ответов (удаление, создание, редактирование)
3) Если изменения подтверждены, то удалить ответы в локальной базе и скопировать из основной базы все ответы.
4) Если изменения отменены,то удалить ответы в основной базе и скопировать ответы из локальной базы.
5) При закрытии (выхода из редактирования) документа удалить все ответы из локальной базы.
6) Саму локальную базу не удалять, т.к. один и тот же пользователь может работать с несколькими основными документами (а разные пользователи с одним и тем же основным документом не могут).

Меня интересует, кто делал подобный механизм. И как его делал? На мой взгляд, это лучшее, что можно придумать. Или есть лучше ?
Какие подводные камни могут быть ?

 

[Domino6]

<!--QuoteBegin-Medevic+15:07:2005, 11:37 -->
<span class="vbquote">(Medevic @ 15:07:2005, 11:37 )</span><!--QuoteEBegin-->Какие подводные камни могут быть ?

[snapback]22211" rel="nofollow" target="_blank[/snapback]​

[/quote]
Потеря (изненение на другой) UNID документов следсвие старые линки на ответы не будут работать.

 

[Medevic]

<!--QuoteBegin-Domino6+18:07:2005, 16:44 -->
<span class="vbquote">(Domino6 @ 18:07:2005, 16:44 )</span><!--QuoteEBegin-->Потеря (изненение на другой) UNID документов следсвие старые линки на ответы не будут работать.

[snapback]22304" rel="nofollow" target="_blank[/snapback]​

[/quote]
Уже столкнулся.
Решил сохранением старого и восстановлением его потом.

 

[Domino6]

<!--QuoteBegin-Medevic+18:07:2005, 16:56 -->
<span class="vbquote">(Medevic @ 18:07:2005, 16:56 )</span><!--QuoteEBegin-->Решил сохранением старого и восстановлением его потом.

[snapback]22305" rel="nofollow" target="_blank[/snapback]​

[/quote]
Попробуй работать с "версионностью" документа а в зависимости от желания пользователя заменять версию или возвращаться к старой.
Но не убивай документ а делай замену всех итемов так сохраниш ИД

 

[Veselinka]

ГОда 4 назад мы пробовали внедрять в лотус понятие транзакции на уровне бизнес логики приложения.
Тоже копирование куда-то, изменение и перекрытие старой версии.
Но реально добиться транзакционности этим механизмом не удасться, так как само понятие "копирования нескольких документов" в рамках одной транзакции в лотусе отсутствует. То есть риск разрыва транзакции вы просто сместите с события изменения документов на событие их копирования.

Если бы мне "кровь из носа" надо было добиться транзакционности и просто крайнее уменьшение вероятности разрыва транзакции меня бы не устраивало, то я бы:
вариант 1) использовала другую платформу, а не лотус
вариант 2) выполняла действия требующие транзакционности в реляционной базе, а в лотус по расписанию заливала результат выполнения транзакции, причем организовала бы "гарантированную заливку результата"

В вашем случае, оцените прежде всего - вам правда нужны транзакции в лотусе? Очень часто встречается попытка внедрить транзакционность со стороны пришедших на лотус недавно с реляцоннок. Но как правило реально это не нужно - достаточно уменьшить вероятность сбоя за счет логически правильного кодирования.

Если данные настолько критичны к непротиворечивости (например финансовые проводки) - используйте лучше не лотус.

В лотусе же например для минимизации сбоя - ведите журнал событий, которые порождают транзакцию - то есть кнопку нажали - записали в журнал, запустили логику.
Если транзакция упала в середине - потом по расписанию - просто доведите ее до конца и запишите в журнал что она завершена....
Очень часто можно использовать механизм "гарантированной доставки" результата транзакции, а не саму транзакционность.

 

[Medevic]

Спасибо за подробное изложение.
Транзакция нужна. Документы в базу в попадают и изменяются в основном пачками. Поэтому желательно перед применением изменений посмотреть что будет.
От локальной базы для хранения копий я отказался, т.к. непонятно что там со встроенными представлениями. В моем случае не нужен мощный алгоритм. Достаточно сделать, чтобы непроверенные документы в базу не попадали и при ошибке заполнения документов через скрипт была возможность отмены изменений.
Вроде нормально получилось. Сейчас тестируется.

А в чем заключается "риск разрыва транзакции" ?

 

[Veselinka]

Риск разрыва - падение процесса в середине по какой-то причине - например падение сервера, падение клиента, выполняющего логику, просто ошибка в коде, приведшая к падению, можно придумывать ситуации дальше