_bob,

По-моему, Вы что-то напутали.

https://msdn.microsoft.com/ru-ru/library/ms173763.aspx READ UNCOMMITTED
Указывает, что инструкции могут считывать строки, которые были изменены другими транзакциями, но еще не были зафиксированы.

Транзакции, работающие на уровне READ UNCOMMITTED, не используют совмещаемые блокировки, чтобы предотвратить изменение считываемых текущей транзакцией данных другими транзакциями. Транзакции READ UNCOMMITTED также не блокируются монопольными блокировками, которые не позволили бы текущей транзакции считывать измененные другими транзакциями, но не зафиксированные строки. Установка этого параметра позволяет считывать незафиксированные изменения, которые называются чтением«грязных» данных. Значения в данных могут быть изменены и до окончания транзакции строки могут появляться и исчезать в наборе данных. Этот параметр действует так же, как и настройка NOLOCK всех таблиц во всех инструкциях SELECT в транзакции. Это наименьшее ограничение уровней изоляции.

В SQL Server конфликты блокировок при защите транзакций от чтения «грязных» данных незафиксированных изменений данных можно сократить с помощью следующего:

•уровня изоляции READ COMMITTED с параметром базы данных READ_COMMITTED_SNAPSHOT, находящимся в состоянии ON;


•Уровень изоляции моментального снимка (SNAPSHOT).


...

SERIALIZABLE
Указывает следующее.

•Инструкции не могут считывать данные, которые были изменены другими транзакциями, но еще не были зафиксированы.

•Другие транзакции не могут изменять данные, считываемые текущей транзакцией, до ее завершения.

•Другие транзакции не могут вставлять новые строки со значениями ключа, которые входят в диапазон ключей, считываемых инструкциями текущей транзакции, до ее завершения.
Блокировка диапазона устанавливается в диапазоне значений ключа, соответствующих условиям поиска любой инструкции, выполненной во время транзакции. Обновление и вставка строк, удовлетворяющих инструкциям текущей транзакции, блокируется для других транзакций. Это гарантирует, что если какая-либо инструкция транзакции выполняется повторно, она будет считывать тот же самый набор строк. Блокировки диапазона сохраняются до завершения транзакции. Это самый строгий уровень изоляции, поскольку он блокирует целые диапазоны ключей и сохраняет блокировку до завершения транзакции. Из-за низкого параллелизма этот параметр рекомендуется использовать только при необходимости. Этот параметр действует так же, как и настройка HOLDLOCK всех таблиц во всех инструкциях SELECT в транзакции.

Таким образом, продать три раза билет на одно и то же место можно как раз при уровне изоляции READ UNCOMMITTED, если все три транзакции "квазиодновременно" определили в транзакции, что место еще не продано, а затем продали его также "квазиодновременно".

Уровень SERIALIZABLE не позволит прочитать статус места, пока с ним работает другая транзакция. Однако, это вызовет дополнительные "тормоза".

_bobGaryaПардон, продать три раза одно и то же место может получиться и при том, и при этом уровне изоляции - зависит от логики работы транзакции.

ну наконец-то Garya понял что я имею в виду
и наверняка понял, почему я настаиваю на последовательном пересчете )))Решил удалить свой пост и написать более детально, извините, коллеги. Кто-то успел увидеть краткое резюме без объяснения.

SERIALISEBLE вызывает блокировку данных только после записи в одной из параллельных транзакций. Однако, прочитать, что место свободно могут все параллельные транзакции перед модификацией статуса места. Если логика работы такова, что пытается модифицировать статус, предварительно проверив его, может возникнуть ситуация, когда три параллельных транзакции установили факт, что место - свободно. Затем та из транзакций, которая попытается модифицировать значение первой, установит блокировку на данные. Вторая и третья транзакции выполнить модификацию не смогут - у них возникнет ошибка блокировки.

Если эта ошибка корректно обрабатывается на клиенте, тогда клиент попытается повторно считать статус и модифицировать его. Если она не обрабатывается, либо обрабатывается некорректно, либо проверка статуса места и модификация производятся в разных транзакциях, могут возникнуть проблемы. Однако, в общем случае SERIALIZEBLE как раз лучше защищает от подобных ситуаций, нежели READ UNCOMMITED. Однако, SERIALIZEBLE может вызвать вал взаимных блокировок и страшные тормоза.

Так что, с моей точки зрения s_ustinov всё же более прав, нежели _bob, который не нашел в себе силы признать 20084955 , что перепутал эти уровни изоляции, хотя и начал в своем ответе корректировать свою позицию.

Коллеги, по моему, Вы слишком ополчились друг на друга. Человеку свойственно ошибаться, не следует злорадствовать по поводу чужих ошибок, потому что когда-нибудь ошибетесь и вы. И _bob, и s_ustinov - оба весьма грамотные специалисты. Но, к великому моему сожалению, не достаточно сдержанные. Подобная несдержанность - весьма нехарактерная черта для ИТ-директоров, которые должны иметь в себе силы сдерживать эмоции, это одно из ценных качеств менеджера высокого уровня. И не только менеджеров, но и вообще всех людей, которые считают себя интеллигентными и не хотят опускаться до базарного уровня.

Модератор: Если попытки взаимных наездов не прекратятся, мне придется данный тред прикрыть, а нарушителей забанить.