Читаю описание
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 или запускать рестарт?
