Читаю описание 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).


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

Exteris,

это на случай наша транзакция мега длительная, а пока она выполняется завершаются 10 и более коротких, причём старт-коммиты должны ещё и не удачно попасть до рестарта и каждый раз после рестарта. Конечно сценарий маловероятный, но мало ли

кстати. Может вопрос немного не в тему, но мало ли есть связь.
Планируется ли сделать так чтобы запросы к MON$ вели себя по разному в зависимости от уровня изолированности транзакции?
Раньше вроде RC был не очень пригоден поэтому для MON$ всегда работал SNAPSHOT, а теперь вроде как доступна консистентная информация на уровне запроса.

kdv,

так оно и так в новом RC снимок. Вот только для обновления информации в MON$ сейчас надо перезапускать транзакцию, а для ряда случаев достаточно было бы просто перевыполнить запрос. Т.е. можно было бы менять поведения в зависимости от того где запрашивается информация из MON$ в RC или SNAPSHOT

Dimitry Sibiryakov,

Такая ситуация потенциально может быть если ты только обновляешь не меньше миллиона строк. Это и без всяких рестартов будет больно

Dimitry Sibiryakov,

и что одновременно эти 5 миллионов кто-то ещё правит? Ну предположим правит, вот будет облом апдейту, запустят его снова с клиента. Что будет быстрее что ли?
Вроде эта одна из тех операций которая должна завершится в любом случае. А вот диагностика конечно нужна. Можно например ввести в MON$STATEMENTS счётчик рестартов

Симонов Денис,

точнее в MON$RECORD_STATS

hvlad,

в RDB$TYPES для MON$ISOLATION_MODE забыли добавить
4 - READ_CONSISTENCY

точнее READ_COMMITED_CONSISTENCY. Ну вам виднее как назвать