И снова здравствуйте.

Имеется три таблицы:


В один прекрасный момент требуется обновить поле value в таблицах MEMBERS и RECORDS для некоторого id_grp. При этом они должны быть обновлены все разом, в одной транзакции. Само обновление выглядит так: считывается текущее значение, обрабатывается, на его место записывается новое, кроме того эти поля в этих таблицах зависимы друг от друга. В силу непреодолимых технических причин процесс обновления может занимать до нескольких [десятков] минут и по его завершению не обновлённые записи становятся невалидными. Соответственно, если в этот момент какой-то пользователь изменит запись или добавит новую в таблицу RECORDS с этим же id_grp (читать можно), то процесс придётся начинать сначала.

Вопрос: как правильно реализовать такое обновление?

pastoralekcvp,
select for update испробован?
Нет ещё, я вот и интересуюсь в каком направлении копать. Спасибо.

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

YuRockalekcvpЭто не помешает добавлению новых записей, как я понимаю?
Нет, конечно не помешают. Но если должно помешать - то ни update, ни select for update не помогут.
Ну в данный момент у меня тупо блокируются все три таблицы на изменение, но мне почему-то кажется что это неверный подход...

А запрос вида: update table set id = id where ... вызывает реально какие-нибудь изменения в базе или нет?

Ещё есть идея поставить в records триггер на добавление записей типа: select id from groups where id = new.id_grp with lock; и тогда добавление будет обламываться, если запись в groups уже заблокирована кем-то.

Мимопроходящий23.04.2018 17:33, alekcvp пишет:
> Ещё есть идея

способов достичь нирваны через анус превеликое множество.
но нужно ли тебе это, при нормальной ориентации?

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

Mikle83alekcvp,
Мало выходных данных:
акт вандализма разовый или периодически планируется?
Влиять на "вне субдшную" логику/алгоритмы есть возможность?
Падение производительности на время обновления критично?

Если Да, то логично для группы ввести флаг активен/нет.
Анализировать его на клиенте (?вьюхах/процедурах).

Тогда задача обновления не будет столь критичной.

Если нет, запрет реализуется через триггер: если на запись (группу?)
выставлен флаг - запрет обновления, вставки данных.

Основная цель: избежать длительной и большой транзакции.
Цена: производительность

1. Разовый, но неоднократный, в смысле изредка возникает необходимость.
2. Есть, но не хотелось бы плодить сущности в виде дополнительных таблиц. К тому же это "псевдотрёхзвенка", т.е. приложение взаимодействует только с ХП.
3. Производительность вообще не критична, желательно чтобы во время обновления можно было получить доступ к незатронутым
обновлением записям.

Флаг - это хорошо, но если во время обновления приложение будет убито по какой-либо причине? Флаг в базе так и останется, группа станет недоступна и придётся лезть в базу "руками".

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

В итоге сделал следующее:

1. Добавил в таблице групп поле grplock;
2. Когда пользователь запрашивает права на запись в эту группу, то это поле проверяется и если оно не null то он посылается;
3. Добавил ХП LOCK_GROUP(gid, locked), которая делает нехорошую вещь:

т.е. даже внутри транзакции она обновляет это поле и изменения видны всем. Если во время обновления данных произойдёт какой-либо exception, то она вызывается ещё раз с locked = 0, после чего транзакции делается rollback.

4. В дисконнект триггер добавил



P.S: Пишущая транзакция nowait.