Коллеги,

помогите, пожалуйста, придумать пример из какой-нибудь
общепонятной предметной области, иллюстрирующий
аномалию из

http://www.postgresql.org/docs/8.0/static/transaction-iso.html#MVCC-SERIALIZABILITY

Хочется вместо class и value что-нибудь более жизненное, берущее,
я бы сказал, за душу.

Есть похожий пример, где одна транзакция удаляет родителя, потому
что у него нет ребенка, а другая в это же время
убеждается в существовании родителя и создает к нему
ребенка - тут все просто, но хочется более похожего на постгресовский
пример, чтобы SELECT FOR UPDATE не помогал.

Спасибо.

баззззлайтерХм, а select for update (у нас называется updlock,holdlock) вроде бы и обеспечивает блокировку по предикатам. Только очень большие объёмы данных приходится блокировать в начале транзакции, если неизвестно какие запросы могут быть в конкурирующей транзакции.
И проблема в том примерчике тоже на блокировках объезжается.

- не знаю, у кого именно select for update называется updlock
- согласен с полезностью предикатных блокировок; о том, какое отношение они имеют к реальной жизни, можно почитать на той же странице по соседству с примерчиком
- буду очень признателен за другие похожие примерчики - именно об этом я и просил в своем письме.

Спасибо.

softwarerЭэ.. по-моему, не совсем так. Правда, я дилетант в MSSQL, так что поправьте, если скажу глупость.

Прежде всего, в BOL написано, что updlock просто ставит на строки update-блокировку вместо shared. Таким образом, блокировки по предикатам (то есть блокировки insert-а записи, отвечающей условию, либо update-а записи в запись, отвечающую условию) он не делает.Что касается holdlock - это выполнение в режиме serializable.


Я в MS SQL даже не дилетант, а наблюдатель-со-стороны, так что ограничусь вопросом.

Правильно ли я понимаю, что holdlock (он же serializable) без updlock обеспечивает-таки блокировку по предикатам (возможно, блокируя при этом что-то лишнее)?

Спасибо.

Только "предикатную блокировку holdlock в каком-то смысле обеспечивает" - нельзя говорить. Это неправда. Я плохо сформулировал, а Вы ещё хуже. В сиквеле нет предикатных блокировок. Просто, есть практика блокировать страницы данных, которые-могли-бы-попадать-в-запросы конкурирующих транзакций.
Отличие в том, что Вы сами решаете, какие запросы могут быть - а не сервер.

Вы, судя по всему, друг друга еще понимаете, а вот я уже нет ;((

Давайте определим предикатную блокировку как гарантию того, что результаты любого запроса будут такими же, как и в первый раз. Обеспечивается ли это в MS SQL при Isolation Level Serializable?

Если приведенное выше определение предикатной блокировки не кажется удачным (или правильным), то какое нравится больше?

Отдельно буду признателен за рассказ про эскалацию блокировок в MS SQL.

softwarer ilejnДавайте определим предикатную блокировку как гарантию того, что результаты любого запроса будут такими же, как и в первый раз. Обеспечивается ли это в MS SQL при Isolation Level Serializable?
Ээ.. сформулированное - это repeatable read.


Мне кажется, что мое определение гарантирует отсутствие Phantom Read, т.е. соответствует определению Serializable из SQL'92.
Вы так не считаете?

ilejnОтдельно буду признателен за рассказ про эскалацию блокировок в MS SQL.
возможно, поможет

Спасибо за ссылку.

Эскалация блокировок мне (и автору вышесосланной статьи) представляется механизмом для регулировки производительности сервера.

Имея некоторые тайные знания о функционировании этого механизма(например, MS SQL guru может точно знать, что SELECT * from T where ID>100 приводит к блокировке всей таблицы и не дает вставить новую записьс ID 1000, что и требовалось для предикатной блокировки), действительно можно говорить о связи эскалации блокировок с предикатными блокировками. У меня эти тайные знания отсутствуют, так что хотелось бы комментариев.

Спасибо.

- Repeatable read требует, чтобы повторное чтение вернуло те же данные, что и первое.


Возможно, все дело в нюансах использования русского языка.
Вы пишите "вернуло те же данные", а я "результаты запроса".

Repeatable Read гарантирует, что те строки, которые однажды вернул некоторый запрос, будут неизменны в дальнейшем. При этом, этот же "некоторый запрос" вполне может вернуть дополнительные строки.

Например, SELECT MAX(VALUE) FROM TBL при REPEATABLE READ имеет полное право быть разным, а вот при SERIALIZABLE он одинаков.

С другой стороны, если при Repeatable Read мы прочли запись с ID=345, то она должна остаться неизменной на протяжении транзакции.

- Serializable требует, чтобы запрос вернул данные на начало транзакции. Те данные, которые вернул бы запрос, будь он выполнен в момент start transaction.


Согласно стандарту, Serializable гарантирует отсутствие Phantom Read. Чуть раньше по тексту стандарта написано, что должно быть гарантировано такое конечное состояние данных, как если бы транзакции исполнялись последовательно.

Насколько я понимаю, транзакция с ISOLATION LEVEL SERIALIZABLE имеет полное моральное право прочитать данные, модифицированные после ее начала, и в блокировочниках это реально происходит.

Я заблуждаюсь?

Я спутал стандартный repeatable read с более сильной изоляцией, которую оракл делает в read-only транзакциях.


Отлично. Мой любимый терновый куст и хороший повод вернуться к началу обсуждения.

SET TRANSACTION READONLY это то самое, из чего в Oracle вырос-таки некий уровень изоляции, названный Serializable. Различия между этим Serializable и Serializable в смысле стандарта отражены в
http://www.postgresql.org/docs/8.0/static/transaction-iso.html#MVCC-SERIALIZABILITY
Там все хорошо, кроме нежизненных примеров.
Я очень надеюсь, что коллективная фантазия, основанная на прочных знаниях, приобретенных в результате внимательного изучения сообщений в данной нити, способна породить что-нибудь интересное и понятное предпоследнему бухгалтеру ;)
А?

То, что привел здесь баззззлайтер, либо нерелевантно, либо я чего-то не понимаю, и хотел бы дополнительных объяснений.

Спасибо.

Мне трудно привести пример, в котором serializable transaction не обеспечивает true serializibility в терминах того документа. SQL сервер блокирует все записи, которые ему приходилось просмотреть, чтобы получить результат - а не только те, которые в результат попали.


Какой SQL сервер? MS SQL? Исходный вопрос касался версионников. И "тот документ" говорит о различиях между true serializability и поведением версионников. Пример демонстрирует достижение результата, которого просто не может быть при true serializability, он очень простой, но несколько оторванный от жизни.

Вы увидите, что транзакция получила Exclusive lock на таблицу. Несмотря на rowlock. Понятно, что конкурентная транзакция будет заблокирована, и не сможет вкатать ещё одну строчку с name=masha, и этим нарушить serialazibility.


В примере транзакция начинается только при подсчете суммы. Да, при выборе Serializable мы ее подсчитаем на некоторый строго определенный момент. Отлично. Все хорошо и здорово.

Основная проблема этого примера (или ограниченности моего мировосприятия) состоит в отсутствии описания решаемой задачи, после чего становится непонятно, как данные должны были бы выглядеть при true serializability, и что с чем мы сравниваем.