автордаже в версионнике в двух транзакциях используя FOR UPDATE можно получить deadlock при read commited, а при Serializable и без FOR UPDATE?Дедлок вы получите всегда, независимо от уровня изолированности транзакции, если коннект_1 заблокировал строку_1 и хочет заблокировать строку_2, а коннект_2 заблокировал строку_2 и пытается заблокировать строку_1.
Куда важнее другое:
1) приведет ли вывал сообщения о дедлоке в одном из окон к АВТОМАТИЧЕСКОМУ снятию блокировок, которое оно установило перед этим, и след-но, к возможности ДРУГИХ окон (НЕ "жертв") продолжить свою работу;
2) что в итоге будет записано в таблицу, строки которой оказались "втянуты в конфликт"

Результаты, получаемые в Firebird при возникновении дедлоков, зависят не только от действий сервера! Крайне важно и то, как спроектировано клиентское приложение, реагирует ли оно вообще на получаемые ошибки и откатывает ли ПОЛНОСТЬЮ проделанные изменения.
Прочтите вот эту статью: http://www.ibase.ru/devinfo/savepoints.htm

И проведите затем нижеследующий эксперимент (я делал с уровнем = RC, попробуйте SNAPSHOT - будет тоже самое):
DDL:
Сценарий 1_a.
W1: isql -n test.fdb
W2: isql -n test.fdb
W1: commit; set transaction read write read committed NO RECORD_VERSION wait;
W2: commit; set transaction read write read committed NO RECORD_VERSION wait;
W1: update tmp set val=val*10 where id=1;
W2: update tmp set val=val*1000 where id=2;
W1: update tmp set val=val*10 where id=2;
W2: update tmp set val=val*1000 where id=1;
/* через 10 сек (по дефолту, см. firebird.conf, параметр DeadlockTimeout) в одном из окон вывалится сообщение:

ВНИМАНИЕ: вывод этого сообщения НЕ является завершением транзакции! Она в этом окне всё еще активна.
В другом окне НИКАКОГО действия произведено не будет до тех пор, пока в "аварийном" не будет выдано COMMIT или ROLLBACK; там идёт БЕСКОНЕЧНОЕ ожидание завершения транзакции в "аварийном" окне.
В моём случае "авария" произошла в ПЕРВОМ окне, W1.
*/
W1: commit; // по-хорошему, надо конечно делать ROLLBACK. Но мы "поиздеваемся" и проверим, что будет в итоге :-)
W2: управление в окне МОЛЧА вернулось к подсказке "SQL>" , НИКАКИХ сообщений выведено не было.
Смотрим в этом же кне, что сейчас в таблице:
W 2 : SELECT * FROM TMP;
Result: W2: COMMIT;

ВЫВОД. В этом режиме транзакция, в которой НЕ было "аварии", действительно может после обнаружения сервером дедлока провести обновление ВСЕХ ("ЧУЖИХ") записей, которые были заняты. "Аварийный" же сеанс, свалившийся на N-ом операторе с начала транзакции (в этом сценари - на втором операторе), сможет зафиксировать только действия, выполненные (N-1) ПРЕДЫДУЩИМИ операторами.

Сценарий 1_b.
W1: isql -n test.fdb
W2: isql -n test.fdb
W1: commit; set transaction read write read committed NO RECORD_VERSION wait;
W2: commit; set transaction read write read committed NO RECORD_VERSION wait;
W1: update tmp set val=val*10 where id=1;
W2: update tmp set val=val*1000 where id=2;
W1: select * from tmp;
/*
Теперь окно_1 будет БЕСКОНЕЧНО долго висеть в ожидании высвобождения блокировки, установленной на строку с ID=2 окном_2.
Эта ситуация НЕ является дедлоком: W1 не пытается установить блокировку, оно просто хочет прочитать незакоммиченные данные, находясь в транзакции, настройки которой явно ЗАПРЕЩАЮТ это делать.
ИМХО, всё-таки сообщение сервер здесь мог бы выдать, так же через время, определяемое параметром DeadLockTimeout (только убрать бы из его названия слово "Dead" - и всё будет выглядеть вполне логично :))
*/

Сценарий 2_a.
W1: isql -n test.fdb
W2: isql -n test.fdb
W1: commit; set transaction read write read committed RECORD_VERSION wait;
W2: commit; set transaction read write read committed RECORD_VERSION wait;
W1: update tmp set val=val*10 where id=1;
W2: update tmp set val=val*1000 where id=2;
W1: update tmp set val=val*10 where id=2;
W2: update tmp set val=val*1000 where id=1;
/*
Также через 10 секунд в одном из окон появится сообщение о дедлоке, но уже более информативное:
В моём случае это опять оказалось окно W 1 . Транзакция в это окне НЕ завершена - так же, как и в предыдущем сеансе.
Управление во ВТОРОМ окне (НЕ "аварийном", также как ранее, НЕ возвращается к подсказке "SQL> " - оно будет висеть бесконечно, до тех пор пока в первом окне не будет завершена транзакция
*/

W1: COMMIT ; // опять будем проверять этот случай, а не ROLLBACK :-)
W2: Вместо "молчаливого" возврата управления к подсказке появилось сообщение: - и только после него появилась подсказка "SQL >"
W2: COMMIT;
W1 (или W2): SELECT * FROM TMP;
Result:
А теперь сравниваем эти данные с теми, что были получены в сценарии 1_а.

ВЫВОД 2_а. Даже если транзакция не оказалась в роли "жертвы" (т.е. сообщение о дедлоке появилось сначала в ДРУГОМ окне), она всё равно в итоге НЕ сможет провести свои изменения в полной мере . Изменена только строка с ID=2, т.е. та, которая была СРАЗУ (без конфликтов) заблокирована с самого начала этой транзакции.
В чём причина этого ? В том, что когда "аварийное" окно W1 получило сообщение о дедлоке, оно упрямо закоммитило изменения, которые выполняло предыдущим оператором. Это было изменение строки с ID=1. Именно этот коммит и послужил обломом для "нормального" окна W2 - см. ниже, сценарий 2_b.

Сценарий 2_b.
W1: isql -n test.fdb
W2: isql -n test.fdb
W1: commit; set transaction read write read committed RECORD_VERSION wait;
W2: commit; set transaction read write read committed RECORD_VERSION wait;
W1: update tmp set val=val*10 where id=1;
W2: update tmp set val=val*1000 where id=2;
W1: update tmp set val=val*10 where id=2;
W2: update tmp set val=val*1000 where id=1;
/*
Снова через 10 секунд в окне W1 появится сообщение о дедлоке:
*/
W1: ROLLBACK;
W2: а вот теперь никакого сообщения о дедлоке нет (в отличие от сценария 2_а) и управление "молча" вернулось к подсказке "SQL >"
W2: COMMIT; SELECT * FROM TMP;
Result: ВЫВОД 2_b. Если возник дедлок и некоторое окно оказалось выбрано сервером "жертвой", то другое окно, заинтересованное в данных этой "жертвы", сможет обновить их ТОЛЬКО при условии, что "жертва" выполнила ROLLBACK.

версионникВ данном случае при Read Commited на какой строке обломиться и по причине Update conflict или Deadlock?На третьей строке, при условии что эта транзакция (T1) запущена с параметром RECORD_VERSION, она получит облом через 10 сек.
Если же она запущена с параметром NO RECORD_VERSION, то будет бесконечное ожидание.

Dimitry SibiryakovТаблоидЕсли же она запущена с параметром NO RECORD_VERSION, то будет бесконечное ожидание.

Перестал бы ты использовать кривые уровни изоляции только потому, что их поведение
напоминает Оракула... Read Committed - наше всё!
я всего лишь показал ТС'у, какие будут эффекты :-)

версионникКстати, версии данных в версионниках создаются только при DML?в ФБ версии создаются только при insert, update(merge) и delete. В случае с апдейтом поля на то же значение, которое в нём было до этого записано, версия не создастся. Селект версию тоже не создаст. Наглядно про версии рассказано тут .