Привет. Запустил два инстанса аппликашки для Firebird 2.5 embedded со следующими параметрами транзакции:
ZeosLibisc\_tpb\_version3
isc_\tpb\_write
isc\_tpb\_wait
isc\_tpb\_read_committed
isc\_tpb\_no_rec_version


Прокрутил следующий юз кейс:
1) 'UPDATE TEST SET id = ?' из первой транзакции
2) 'UPDATE TEST SET id = ?' из второй транзакции (=> зависла, поскольку _wait, ожидаемо)
3) Commit или rollback первой => вторая вывалилась с сообщением:

автор---------------------------
Project1
---------------------------
SQL Error: deadlock update conflicts with concurrent update concurrent transaction number is 3115669. Error Code: -913. deadlock The SQL: UPDATE TEST SET id = ?;
---------------------------
OK
---------------------------


Почему так произошло? Ведь в read commited ожидается подчитывание закоммиченных данных, не так ли?

Спасибо за ссылки. Почитал, многое прояснилось. Осталось понять, какой тогда смысл в 'wait', если после него не происходит перечитывание? Фраза из документации
http://www.ibase.ru/ibtrans/ Как выяснилось (в 2010) году, многие разработчики драйверов (Firebird ODBC, Firebird .Net driver (DNET-337) и т. д.) почему-то считают, что для read_committed нормальным является режим no record_version, вызывающий блокировки по чтению non-committed данных. Это является неестественным, т. к. InterBase и Firebird ни при каком уровне изолированности не допускают чтения non-committed данных.

просто убила. У них незакомиченными данными считаются даже те, что прошли коммит во время выполнения стейтмента в read commited.