Здравствуйте, Merle, Вы писали:

R>>А вот менеджера транзакций в понимании блокировочника там нет,
M>Там нет не менеджера транзакций, а менеджера блокировок. А менеджер транзакций там в полне себе есть. Возможно он называется по другому, но это тот самый механизм, который определяет, что вот эта вот транзакция нарвалась на вот эту вот и ее надо откатить, по бырому, чтобы не отсвечивала.

как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть. Сервер никогда не занимается самодеятельностью. Потому что в этом нет никакой необходимости. Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно. И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.

R>>журнала также нет, все гораздо проще — есть страницы, и есть версии записей.
M>Да. Нет журнала, как отдельного файла или механизма, но схема работы с данными действительно напоминает undo-журнал.

напоминает.

R>>1. Смерть сервера по форсмажорным электричествам во время сборки мусора (sweep)
M>Вот здесь вот та самая оговорка про отказоустойчивость. Отказоустойчивость должна обеспечиваться и при работе всех обслуживающие механизмов, а здесь ее нет.

это достаточно редкий случай, который сейчас исправлен как баг.

R>>4. ... Ну еще несколько причин, не таких основных.
M>В том-то и дело, что при полноценном Recovery никаких причин не должно быть в принципе.

неясно, что ты имеешь в виду под Recovery. Давай еще раз услышим определение, в случае каких сбоев надо этот "механизм" применять.

M>Единственная допускаемая возможность невосстановимого сбоя — это случай физического повреждения носителя. Если же повреждения не произошло, то база обязана сама себя привести в корректное состояние без посторонней помощи.

Она и приводит. Просто Romkin излишне углубился в ситуации, которые никакого отношения к версионности не имеют.