Читаю описание https://github.com/red-soft-ru/firebird/blob/read_consistency/doc/README.read_consistency.md
Всё круто. Но хотелось бы пояснений в некоторых моментах.

Update conflicts handlingWhen statement executed within read committed read consistency transaction its database view is not changed (similar to snapshot transaction). Therefore it is useless to wait for commit of concurrent transaction in the hope to re-read new committed record version. Similarly, engine doesn't wait and re-read record when update conflict happens. Instead, engine undoes all work done up to top-level statement, creates new snapshot and restart top-level statement execution. This is the same logic as user applications uses for update conflict handling usually, but it is a bit more efficient as it excludes network roundtrips to\from client host. This restart logic is not applied to the selectable stored procedures if update conflict happens after any record returned to the client application. In this case isc_update_conflict error is returned.


Почему решили именно так обрабатывать конфликты обновлений в READ COMMITTED READ CONSISTENCY. Я согласен что в большинстве случаев когда пользователь нарывается на конфликт обновлений, он скорее всего попытается проделать тоже самое после завершения конкурирующей транзакции, но далеко не всегда. Может всё таки ввести дополнительные параметры транзакции, которые позволяют решить бросать ли ошибку isc_update_conflict или запускать рестарт?

Dimitry Sibiryakov,

про рестарты Оракла я в курсе. Мне интересно почему нельзя дать выбор как обрабатывать конфликт обновлений.

hvlad,

Хороший пока в голову не приходит.
Это зависит от бизнес-логики. Далеко не всегда необходимо чтобы мои изменения перетерали чужие и я об этом был даже не в курсе. Возможно если я увижу конфликт я вообще не стану делать повторный UPDATE.

Dimitry Sibiryakov,

ну впрочем да. Я всегда могу повысить до concurency. Забыл что по стандарту RC допускает потерю обновлений.
Тогда понятно почему через рестарты сделали.

hvlad,

так если будет автоматически запускаться рестарт, то я никогда этих конфликтов не увижу. Разве нет?

hvlad,

кстати как оно там взаимодействует с SELECT * ... WITH LOCK?

hvlad,

спасибо за разъяснения

hvladДавайте ещё раз уточним - рестарт имеет смысл только в том случае, когда тр-ция-конкурент уже не активна.
Если она активна, то выдаётся обычное сообщение о конфликте в котором первичный код ошибки - isc_deadlock и только вторичная ошибка будет isc_update_conflict.
Если же тр-ция-конкурент не активна, то делается рестрат запроса в новом снимке.
В коде сейчас прописано 10 попыток рестрата, после 10-ой будет выдана isc_update_conflict (без isc_deadlock).


это именно то чего я в описании не увидел, отсюда и возник вопрос.