А что ненадёжного в вызове метода, выполняющего обычную
пессимистическую блокировку перед какой-то последовательностью действий?
У меня немного другая нужда. Надо было сразу поподробнее. Ситуация вообщем
стандартная. Клиент с Апп-Сервера вытаскивает документ. (шапка, детали,
оплаты по документу и т.д. вообщем пачку взаимосвязанных записей).
Вообщем-то после чтения транзакция заканчивается. Пользователь смотрит на
это чудо и в какой-то момент решает что-то исправить. Жмет на кнопку
изменить. И с этого момента надо, чтоб другие не смогли бы в этом же
документе, этой же кнопкой воспользоваться. Вижу два варианта :
1. - С клиента вызываем метод на Апп-сервере, в котором стартуется
транзакция. В ней повторно перечитывается документ с Select For Update With
Lock. Потом клиент изгиляется над документом и по нажатии кнопки
"Сохранить"/"Отказ" происходит либо ApplayUpdates/CancelUpdates в рамках
этой транзакции.
2 - С клиента вызываем метод на Апп-сервере, в котором в список
заблокированных документов на сервере добавляется ID редактируемого
документа, ну и документ еще раз перечитывается, чтоб ползателю свежачок
предоставить.
Я с мидас как-то раньше и не работал. Ну так, детские шалости. Вот
собственно и интересует - какой вариант проще и надежнее в реализации. Может
есть известные глюки и грабли по которым народ уже прошелся. Особо при
обработке обрыва связи с Апп-сервера с клиентом, обрыва связи Апп-сервера
с FB, ну и при падении как FB так и Апп-сервера.
А может еще какой-то способ реализовать данную функциональность есть.
With b/r. Gleb.
