shared-бликировки и read commited

← →
Bless © (2006-02-10 12:08) [0]

Вопрос носит чисто теоретический характер, но все-равно охота разобраться.
Короче, укажите, где я недопонимаю.

Читаем BOL на команду
SET TRANSACTION ISOLATION LEVEL READ COMMITTED

Specifies that shared locks are held while the data is being read to avoid dirty reads

Как я понял из процитированного, установка уровня изоляции транзакции READ COMMITED решает проблему "грязного чтения". Причем, решается эта проблема путем наложения shared-блокировок.

Я несогласен:
"грязное чтение" - это когда (в хронологическом порядке)
1. одна транзакция меняет данные,
2. вторая - читает измененные данные
3. первая транзакция откатывает данные.

В результате вторая транзакция работала с данными, которых нет. Я правильно понимаю "грязное чтение"?

Но если первая транзакция наложит на данные shared-блокировку, то каким образом это решит проблему, ведь shared-блокировка разрешает чтение данных другим транзакциям?
Имхо, для решения проблемы "грязного чтения" должна быть наложена монопольная блокировка.
В BOL ошибка или я где-то торможу?

← →
Johnmen © (2006-02-10 12:27) [1]

1. В рамках одной транзакции меняются данные,
2. В рамках второй - читаются измененные данные, не подтвержденные первой
3. первая транзакция откатывает данные.

>В BOL ошибка или я где-то торможу?

Просто не очень корректно перевёл.

← →
Bless © (2006-02-10 13:16) [2]

А как переводится корректно?

← →
evvcom © (2006-02-10 14:35) [3]

> Имхо, для решения проблемы "грязного чтения" должна быть
> наложена монопольная блокировка.

В Oracle эта проблема решена без блокирования.

← →
Nikolay M. © (2006-02-10 15:01) [4]

> evvcom © (10.02.06 14:35) [3]

И к чему ты написал этот пост? В огороде бузина, а в Киеве дядька...

> Имхо, для решения проблемы "грязного чтения" должна быть
> наложена монопольная блокировка.

Так и есть. Если ты посмотришь на таблицу совместимости блокировок, то увидишь, что X- и S-блокировки несовместимы друг с другом. Т.е. если один процесс наложил на некий ресурс X-блокировку, то другой процесс, при попытке наложения на тот же ресурс S-блокировки, будет ждать окончания X-блокировки - так и решается проблема грязного чтения.

← →
Bless © (2006-02-10 15:03) [5]

>В Oracle эта проблема решена без блокирования.

Я имел в виду только MSSQL (не Yukon)

← →
Bless © (2006-02-10 15:07) [6]

Nikolay M. © (10.02.06 15:01) [4]
> Так и есть. Если ты посмотришь на таблицу совместимости
> блокировок, то увидишь, что X- и S-блокировки несовместимы
> друг с другом. Т.е. если один процесс наложил на некий ресурс
> X-блокировку, то другой процесс, при попытке наложения на
> тот же ресурс S-блокировки, будет ждать окончания X-блокировки
> - так и решается проблема грязного чтения.

Угу.
Тогда, выходит, ошибка в BOL.
Я засомневался было, потому что написанное в BOL (что нужна S-блокировка), совпадает с написанным в книге. Видимо, авторы книги просто переводили справку :)

← →
Nikolay M. © (2006-02-10 15:13) [7]

> Bless © (10.02.06 15:07) [6]
> Тогда, выходит, ошибка в BOL.

Где и в чем именно ошибка? При установке

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

все последующие селекты в данной сессии будут читать только COMMITTED-данные, о чем тебе БОЛ и сообщает.

← →
Bless © (2006-02-10 15:34) [8]

>Где и в чем именно ошибка?

READ COMMITTED

Specifies that shared locks are held while the data is being read to avoid dirty reads

>все последующие селекты в данной сессии будут читать только COMMITTED-данные

Да я не сомневаюсь, что это отработает, как должно.

← →
Nikolay M. © (2006-02-10 15:43) [9]

> Specifies that shared locks are held while the data is being
> read to avoid dirty reads
>
> >все последующие селекты в данной сессии будут читать только
> COMMITTED-данные

Вторая строка - нестрогий перевод БОЛ. Ошибки в упор не вижу :(

← →
Val © (2006-02-10 16:00) [10]

можно так перевести эту фразу, мне кажется:
"Указывает, что shared-блокировки будут поддерживаться/устанавливаться при чтении данных для избежания "грязного чтения" "

← →
Bless © (2006-02-10 16:20) [11]

> > >все последующие селекты в данной сессии будут читать
> только
> > COMMITTED-данные
>
>
> Вторая строка - нестрогий перевод БОЛ. Ошибки в упор не
> вижу :(

Я вторую строку никак не комментировал и в ней нет ошибки.
Я же привел цитату и выделил в [8] жирным ошибочное, по моему мнению, место.
Как бы ты перевел ее?
READ COMMITTED Specifies that shared locks are held while the data is being read to avoid dirty reads

Я так:
слова READ COMMITED обозначают, для избежания "грязного чтения" держатся S-блокировки , пока читаются данные.

Разве тут нет ошибки?

← →
Bless © (2006-02-10 16:22) [12]

> Val © (10.02.06 16:00) [10]
>
> можно так перевести эту фразу, мне кажется:
> "Указывает, что shared-блокировки будут поддерживаться/устанавливаться
> при чтении данных для избежания "грязного чтения" "

Угу.
А должно бы быть, имхо,
"Указывает, что exclusive-блокировки будут поддерживаться/устанавливаться
> при чтении данных для избежания "грязного чтения" "

← →
Nikolay M. © (2006-02-10 16:35) [13]

> Bless © (10.02.06 16:22) [12]
> А должно бы быть, имхо,
> "Указывает, что exclusive-блокировки будут поддерживаться/устанавливаться

Нет, не должно. Эксклюзивная котировка наложится при изменении данных, а не при чтении. Об этом я писал еще в [4], или ты тот пост проигнорировал, или не удосужился понять, иначе подобных вопросов больше не возникло бы.

← →
Bless © (2006-02-10 17:09) [14]

> Nikolay M. © (10.02.06 16:35) [13]
>
>
> > Bless © (10.02.06 16:22) [12]
> Нет, не должно. Эксклюзивная котировка наложится при изменении
> данных, а не при чтении. Об этом я писал еще в [4], или
> ты тот пост проигнорировал, или не удосужился понять, иначе
> подобных вопросов больше не возникло бы.

Я в курсе обо всем, написанном в [4].

В [12] посте я ошибся ненарочно.
Вот они издержки сетевого общения, трудно расставить акценты.
Поясню.

Есть фраза из BOL:

"Указывает, что shared-блокировки будут поддерживаться/устанавливаться
> при чтении данных для избежания "грязного чтения"

Я посчитал в ней неправильным не

"Указывает, что shared-блокировки будут поддерживаться/устанавливаться
> при чтении данных для избежания "грязного чтения"

а

"Указывает, что shared-блокировки будут поддерживаться/устанавливаться
> при чтении данных для избежания "грязного чтения"

Я хотел сказать, что shared-блокировки никоим образом не могут помочь избежать "грязного чтения", для этого нужна exclusive-блокировка. Просто, заменив слово shared на exclusive, не обратил внимание на слова "при чтении".

И мой [12] пост в новой редакции должен

А должно бы быть, имхо,
"Указывает, что exclusive-блокировки будут поддерживаться/устанавливаться
> при изменении данных для избежания "грязного чтения"

С таким согласен?

← →
evvcom © (2006-02-10 17:17) [15]

> И к чему ты написал этот пост? В огороде бузина, а в Киеве
> дядька...

А к чему ты Киев приплел?
Насколько я понял, было сделано предположение, что разработчики MS, видимо, некорректно реализовали блокировку. Что по имхо автора
> для решения проблемы "грязного чтения" должна быть наложена
> монопольная блокировка.
Я только обратил его внимание на то, что это, оказывается, не единственный способ решить проблему "грязного чтения". Не более. Потому и бузина, я считаю, тут тоже не к месту.

← →
Nikolay M. © (2006-02-10 17:24) [16]

> Я хотел сказать, что shared-блокировки никоим образом не
> могут помочь избежать "грязного чтения", для этого нужна
> exclusive-блокировка.

Опять не понял. Для того, чтобы не было грязного чтения, нужны две блокировки: "X" при изменении данных и "S" при чтении.

> А должно бы быть, имхо,
> "Указывает, что exclusive-блокировки будут поддерживаться/устанавливаться
> > при изменении данных для избежания "грязного чтения"
>
> С таким согласен?

Нет. Во-первых, повторюсь, ОДНА Х-блокировка не спасет от чтения фантомных данных. А, во-вторых, статья в БОЛ описывает SET TRANSACTION ISOLATION LEVEL, а не механизм блокировок, поэтому фраза о S-блокировке в данном контексте абсолютно верна. О том, как наложение S-блокировки позволяет избежать грязного чтения, нужно читать в других разделах БОЛ.

За сим, поскольку суть блокировок тебе, похоже, ясна, предлагаю закончить трактование и перевод БОЛ-а :)

> evvcom © (10.02.06 17:17) [15]
> А к чему ты Киев приплел?

А к чему ты приплел Оракл, если разговор про MS SQL?

> Насколько я понял, было сделано предположение, что разработчики
> MS, видимо, некорректно реализовали блокировку.

Ты понял неправильно. Вопрос был о не совсем корректной, на взгляд автора, фразе из БОЛ. Надеюсь, после [16] он пересмотрел свое мнение.

> Я только обратил его внимание на то, что это, оказывается,
> не единственный способ решить проблему "грязного чтения".

Теперь понял. Но все равно вопрос был не о том, как в разных СУБД решается вопрос о грязном чтении.

Опять не понял. Для того, чтобы не было грязного чтения, нужны две блокировки: "X" при изменении данных и "S" при чтении.

Гм... Это еще зачем?
Чтобы не было именно "грязного чтения" в s-ке нет нужды.
Наложение s-ки защищает от "неповторяемого чтения", а это уже другая проблема, отличная от "грязного чтения" и совсем другой уровень изоляции.

На простом примере можно убедиться, что s-ка при READ COMMITED не накладывается:
В QA
1.
begin tran SET TRANSACTION ISOLATION LEVEL READ COMMITTED select * from t1 </code запускаем (транзакция незавершена) 2.в другом окне update t1 set kod=5 where nzz=5 update срабатывает, что говорит о том, что s-блокировка первной транзакцией наложена не была. update t1 set kod=5 where nzz=5

> На простом примере можно убедиться, что s-ка при READ COMMITED
> не накладывается:

> select * from t1

А ты в соседнем окне успел посмотреть sp_lock-ом блокировки во время выполнения селекта? Если нет (а я почти в этом уверен), то добавь в селект хинт holdlock и посмотри блокировки или попробуй выпонить апдейт.

Nikolay M. © (10.02.06 18:37) [19]>

Хух, хотел было еще повозражать, но кажись прозрел.

Я подведу итог, а ты поставь, плз, рецензию, а то я в [6] тоже думал, что все окончательно понял.

Раньше я думал, суть
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
заключается в том, что ДРУГИЕ транзакции не могут читать "грязные" данные ЭТОЙ транзакции и тут нужна монопольная блокировка.

На, оказывается, READ COMMITED гарантирует, что ЭТА транзакция тоже не будет читать "грязные" данные ДРУГИХ транзакций. И для этого она пытается наложить s-блокировку.

Я прав?
Жирным выделил новое для себя :)

> READ COMMITED гарантирует, что ЭТА транзакция тоже не будет
> читать "грязные" данные ДРУГИХ транзакций. И для этого она
> пытается наложить s-блокировку.

Маленькая поправка: слово "тоже" не обязательно, в остальном все верно (наконец-то! :) ).
Это я и пытался сказать еще в [4]. Процесс, изменяющий данные, на время изменения данных накладывает на некий ресурс (строка, ключ, страница и тд) Х-блокировку. Если в этот момент попытаться прочитать COMMITTED-данные, относящиеся к этому же ресурсу, то перед чтением на ресурсы должна будет наложиться S-блокировка. А поскольку S и X несовместимы, то перед наложением S-блокировки необходимо дождаться снятия Х-блокировки. И в обратную сторону: после наложения S-блокировки никакой другой процесс не сможет изменить те же данные, т.к. он не сможет наложить Х-блокировку. Так и гарантируется чтение только подтвержденных данных.
При выборке данных на уровне изоляции READ UNCOMMITTED блокировки вообще не накладываются.

Надеюсь, этим постом я тебя не сбил с правильного пути? :)

>наконец-то! :)

Вот уж действительно :)

Спасибо.

shared-бликировки и read commited Найти похожие ветки