Здравствуйте, Кузьменко Д.В., Вы писали:

КДВ> как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть.
Ой. Вот явно чуствуется многоверсионность, сколько людей, столько и объяснений...
А что есть здесь клиентская чать?

КДВ>Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно.
Ну, логично.

КДВ>И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.
О кей, давайте разберемся с самого начала.
Допустим последовательная история транзакций приводит к конфликту. T1 пытается обновить запись, которую уже обновила T2, но при этом T2 еще не успела зафиксироваться.
Далее возможное поведение T1:
1. Ожидание на блокировке.
2. Откат T1 и новый старт.
3. Порождение новой версии данных с которой и работает T1, все разборки произойдут при commit'е (first wins, по классике, кто первый встал, того и тапки, кто не успел, того откатывают)

Кто принимает решение о дальнейшем развитии событий? Клиент? Не, не может быть..
Насколько я понимаю по умолчанию IB поступает по сценарию 2 (но если попросить, то может и по 1, но это не принято)
Ранее. я грешным делом, думал, что по сценарию 3, но тут меня настойчиво поправили..

КДВ>это достаточно редкий случай, который сейчас исправлен как баг.
Гуд.
А в чем именно была проблема?

КДВ>неясно, что ты имеешь в виду под Recovery. Давай еще раз услышим определение, в случае каких сбоев надо этот "механизм" применять.
В случае любых сбоев, если конечно эт сбои не привели к физической порче диска.
Тоесть любой сбой, во время любой операции должен быть обратимым и база должна сама прийти в согласованное состояние на момент непосредственно перед сбоем. (требование Durability из ACID так же не должно нарушаться. Что зафиксировано — не вырубишь топором)

КДВ>Просто Romkin излишне углубился в ситуации, которые никакого отношения к версионности не имеют.
Дык!
Я изначально про версионность ни гу-гу. Recovery, по идее, ни как не зависит от можели Concurrency. Это четыре разных человека.