Yo.!Dimitry SibiryakovСобственно, к применению уровня изоляции ниже serializable нет никаких причин кроме
кривизны конкретной СУБД.

и все таки пользователь ФБ это диагноз.

Вообще чисто теоретически он прав. Другой вопрос насколько у ФБ все хорошо в этом плане.

Люди начинают юзать READ COMMITED и забивать на целостность, или делать ручные блокировки явно не от хорошей жизни :)

Dimitry SibiryakovNitro_JunkieДругой вопрос насколько у ФБ все хорошо в этом плане.
Лучше чем у остальных, поскольку read committed там появился только после того как на IB
наложила лапу Borland, исключительно для совместимости с кривой архитектурой VCL. До этого
практически единственным TIL был concurrency, который как раз и соответствует serializable.


Ну если мериться concurrency, то тогда рулил бы вообще MSSQL с его READ_COMMITED_SNAPSHOT (так как нет оверхеда на чтение данных на начало транзакции). Другое дело что он update conflict'ы кидать не умеет. Понимаю что в этом случае с точки зрения целостности был бы немного мутант, но с точки зрения баланса concurrency - consistency ИМХО наилучший вариант.

hvladDimitry Sibiryakovconcurrency, который как раз и соответствует serializableА ты не зарапортовался ??? Repetable read и serializable не перепутал ?

Там между ними вроде небольшая разница, не? Второй вроде как дополнительно предикаты умеет блокировать, и то ессно не в общем случае.

Nitro_Junkiehvladпропущено...
А ты не зарапортовался ??? Repetable read и serializable не перепутал ?

Там между ними вроде небольшая разница, не? Второй вроде как дополнительно предикаты умеет блокировать, и то ессно не в общем случае.

Блокировать в смысле update conflict'ы кидать :) Не в смысле lock'ов как в блокировочнике... Хотя конечно надо еще почитать как у разных СУБД это реализовано.

Dimitry SibiryakovВо-первых, MS SQL начинался с dirty read, всё остальное ему навешали позже. Отсюда его
странности в виде локов.
Во-вторых, о каком таком оверхэде ты говоришь?


О том что надо определить значение на начало транзакции, по идее для этого нужно больше логов прочитать :) чем если это делать в рамках одного statement'а.

Ну локи кстати дают чуть большую целостность. Хотя конечно она не сравнится с оверхедом.

Dimitry SibiryakovNitro_JunkieО том что надо определить значение на начало транзакции, по идее для
этого нужно больше логов прочитать :) чем если это делать в рамках одного statement'а.
Это у тебя сильно странная идея. Новая версия записи либо создана после savepoint, либо
нет. Нет никакой разницы если этот savepoint уровня запроса или уровня транзакции. Что ещё
больше упрощается если таки принять, что запросы вне транзакции (явной или неявной) не
выполняются.


Тогда может я не совсем понимаю как реализуется "версионный" механизм. Если в системе регистрируются все savepoint'ы и при изменении записи, субд пробегается по всем savepoint'ам и сохраняет для них старое значение, оверхед будет за счет того, что в единицу времени будет больше "активных" savepoint'ов, которые нужно обновлять. Если СУБД определяет предыдущую версию по логам изменений, то тогда оверхед за счет того, что по большему количеству значений нужно пробежать.

Вот никак не могу придумать механизм, чтобы не было оверхеда.