Если он их увидел до того как начал читать запись, и если это READ COMMITTED NO RECORD VERSION тр-ция - ждёт
- если конкурент откатился - читаем и идём дальше,
- если конкурент подтвердился ещё активен, то выдаёт isc_read_conflict,
- если конкурент подтвердился - RC NRV тр-ция читает первичную версию.
Другие тр-ции не ждут и ищут видимую для них бекверсию.

Далее, если запись была нами прочитана, но была изменена конкурентом в промежутке между чтением и самим апдейтом, то снова ждём финального состояния конкурента (если мы READ COMMITTED) и
- если конкурент откатился - пишем свою версию,
- если конкурент ещё активен или подтвердился, то выдаём isc_update_conflict.

Это на пальцах, там больше деталей на самом деле.

PS В 4-ке на уровне READ COMMITTED READ CONSISTENCY алгоритм сложнее и может полностью исключить isc_update_conflict в большинстве случаев

PPS исправил немного

Если tx1 обновила запись и была comitted, то tx2 вполне может её менять. Если tx2 - RC, то неважно кто из них когда стартовал.

А вот это вопрос спорный.Согласен.
Если говорить о пар-рах тр-ции с точки зрения апдейтов, то тот, кто читал хотя бы 22165043 , не мог не заметить, что использование RC NRV
значительно сокращает вероятность конфликтов обновления. Особенно при не очень высокой конкуренции.
Но, конечно, не гарантирует их отсутствие.
Новый режим RC RC в 4-ке уменьшает эту вероятность почти до нуля.

да нет там ничего такого. https://github.com/FirebirdSQL/firebird/blob/master/doc/README.read_consistency.md

Читать до прояснения, особенно главу "Update conflicts handling"

как раз и проверять, завершился он или нет.И как ты собрался это проверять ?


Я же просил - до прояснения. Никто никого не "долбит". Дятлы давно все улетели ;)