AriochalekcvpНу, в идеале, мне хочется чтобы это обновление блокировало только записи связанные с обновляемой группой, позволяя нормально работать со всеми остальными...
Пройдет пару лет, система станет мощнее, и потребуется двумя "исполнителями" одновременно пересчитывать и апдейтить записи для двух разных групп.
Не пройдёт, это "технический" процесс и он запускается не пользователями.
Да и приложение не корпоративного масштаба, так - внутренний софт на один отдел.

Завтра действительно попробую вариант с отдельной таблицей...

AriochalekcvpНу это понятно, идея мне нравится. Но заводить для этого отдельную таблицу...

Лучше завести ОДНУ лишнюю табличку и для блокировки добавлять ОДНУ строку в неё, чем переписывать ВСЕ строки целевой группы
в твоей больше таблицы, даже если из всей группы ты потом только изменишь 1% записей.Сейчас я завёл ОДНО ПОЛЕ в таблице групп и делаю ДВУКРАТНУЮ запись в него на каждый процесс. А в варианте с отдельной таблицей, в неё будут записи (попытки записей) при КАЖДОМ изменении данных в ТРЁХ таблицах. Плюс в моём варианте [если возникнет необходимость] можно проверить блокировку даже из read_commited транзакции и не дать прочитать данные из обновляемой группы. В случае отдельной таблицы с попыткой записи - так не получится.
Ariochкто есть uid ?ID пользователя в таблице пользователей в базе. Т.е. поставить блокировку может кто угодно из тех кто имеет право писать в эти таблицы, а снять - только тот кто поставил. Ну и при дисконнекте по этому значению снимаются блокировки.
AriochalekcvpFireBird 3 поддерживает временные таблицы (которые в базу не пишутся), доступные одновременно всем подключениям?

а если бы поддерживал?

ты не хочешь создавать ещё одну обычную таблицу (со списоком блокировок), но без хочешь создать ещё одну необычную (временную) таблицу?

а в чем разница?В том, что при [аварийном] выключении сервера и при backup/restore не надо париться об этой таблице.
AriochalekcvpЕсли во время обновления данных произойдёт какой-либо exception, то она вызывается ещё раз с locked = 0, после чего транзакции делается rollback.



зачем?

Анекдот про два стакана на ночь у постели программиста?Я же показал - там внутри автономная транзакция, которая в любом случае снимает блокировку, а rollback основной транзакции отменяет изменения, которые уже успел сделать "вывалившийся" процесс.
AriochalekcvpВся операция, требующая блокировки, всё равно должна в одной транзакции выполняться
Но сама блокировка может выполняться предварительно, в отдельной транзакции (если через флаги, в отдельной таблице или в отдельном столбце). Может и так. Но мне проще всё "завернуть" в одну транзакцию.
AriochalekcvpЕсли в этот момент какой-то пользователь изменит запись или добавит новую в таблицу RECORDS с этим же id_grp (читать можно), то процесс придётся начинать сначала.
Вот это была мотивация или требование?
Что должно произойти, если пока мы рассчитываем группу №1 другое соединение пытается удалить или изменить или добавить строку в этой же группе?Ну представьте что там в записях электронные подписи, а в мемберсах - ключи для проверки. Что будет, если при смене этих подписей, кто-то добавит ещё одну запись, подписанную старым ключём (который считывается непосредственно перед подписью)? Если же обновлять сначала ключ, а потом подписи (в разных транзакциях), то кто-то в этот момент может попытаться проверить старую подпись новым ключём и будет облом.

kdvalekcvp,
а что, старый и новый ключ не могут перекрываться по датам? Так ведь и происходит. я получаю новый ключ заранее, до окончания старого.Это был пример для понимания, а не реальная ситуация. По факту там цифровые конверты - ключи в members и сами данные в records. Процесс обновления вызывается когда у кого-то отзывается доступ к группе, для смены ключей.
YuRockalekcvpПлюс в моём варианте [если возникнет необходимость] можно проверить блокировку даже из read_commited транзакции и не дать прочитать данные из обновляемой группы. В случае отдельной таблицы с попыткой записи - так не получится.Транзакция любого типа может прочитать только закоммиченные данные. Так у тебя одна транзакция, или две? Или ты после первого update делаешь CommitRetaining? У меня две транзакции. И проверить значение lock-поля в таблице групп я могу и из читающей, а чтобы попробовать что-то записать в отдельную таблицу и узнать получится или нет - мне придётся обязательно стартовать и пишущую.
AriochalekcvpID пользователя в таблице пользователей в базе. Т.е. поставить блокировку может кто угодно из тех кто имеет право писать в эти таблицы, а снять - только тот кто поставил. Ну и при дисконнекте по этому значению снимаются блокировки.а если клиент отвалился без отрабатывания триггера?Пока думаю над этим, но возможно заставлю ту процедуру, которая проверяет его наличие, проверять (опять же при состоянии locked = 1) так же наличие активной сессии заблокированного пользователя. Ну или перейду на вариант с отдельной таблицей - у обоих вариантов есть свои плюсы и минусы.
AriochAlso, если расчёты идут так долго, то как часто клиент общается с сервером?Хм, мне казалось что я написал: считывает строку, обрабатывает (~10 секунд), запихивает назад.
AriochalekcvpМожет и так. Но мне проще всё "завернуть" в одну транзакцию.
у тебя автономные транзакции летают - это уже едва ли "в одну" В одну с точки зрения приложения, что там в базе происходит - приложению знать не обязательно.
AriochЯ бы очень подумал, прежде чем с блокировками работать асинхронными средствами.Там же написано что автономная транзакция наследует параметры "родительской", родительская - nowait, т.е. либо обновила сразу, либо вывалилась с ошибкой. Или я как-то не так понимаю механизм nowait-транзакций (тоже вариант)?

AriochalekcvpТам же написано что автономная транзакция наследует параметры "родительской"
там во-первых НЕ написано, что родительская транзакция встанет торчком и будет ждать окончания автономки.

Это логически ожидаемо. Иначе можно сказать что нельзя писать хранимки с таким кодом:

Т.к. никто не гарантирует, что на момент insert'a select уже выполнится.
Что звучит как полный бред.

Ariochalekcvpнельзя писать хранимки, Т.к. никто не гарантирует
FB documentationThe body of a PSQL module is a block of statements that run in a logical sequence, like a program.
Это во первых. А во вторых, твой стейтмент выполнился - автономная транзакция запущена. Остальное - детали реализации.

Именно. "block of statements that run in a logical sequence". Т.е. в любой точке хранимки я могу быть уверен, что весь предыдущий код (с учётом ветвлений) уже выполнился, вне зависимости от того в автономной он транзакции или нет. Или с циклами for такая же фигня - он запустился на исполнение, а когда закончится - никто не знает, хранимка дальше пошла?.. :)