Making Snapshot Isolation Serializable.

[tengiz]

zVlad - ну а тогда об чём собственно спорите-то? Те же яйки, вид сбоку - разные имена для одного и того же, пусть даже и нечётко определённого, и поэтому ещё более интересного. Конечно, IBM - признанный пионер в обработке транзакций, да и много ещё где. И что из этого следует?

В общем, аминь.

P.S. А Snapshot у ORACLE (как и у Postgress) - образцово-показательный. Абсолютно безупречный. Блокировки вместо обнаружения конфликтов при commit - всего лишь альтернативная реализация. Во многих смыслах более оптимальная, чем чистая ловля конфликтов записи. Но функционально совершенно экливалентная.

[zVlad]

zVlad - ну а тогда об чём собственно спорите-то? Те же яйки, вид сбоку - разные имена для одного и того же, пусть даже и нечётко определённого, и поэтому ещё более интересного. Конечно, IBM - признанный пионер в обработке транзакций, да и много ещё где. И что из этого следует?

В общем, аминь.

P.S. А Snapshot у ORACLE (как и у Postgress) - образцово-показательный. Абсолютно безупречный. Блокировки вместо обнаружения конфликтов при commit - всего лишь альтернативная реализация. Во многих смыслах более оптимальная, чем чистая ловля конфликтов записи. Но функционально совершенно экливалентная.

Может быть. Вопрос как этот образцово-показательный подход с точки зрения реализации? Многие красивые математические теории не реализуемы на имеющиеся вычислителях.
Такая вот шальная мысль пришла, навеяная Вашим Tengiz:
" .... А по факту, стандарт до сих пор так и не изменён. Хотя уже давно пора." - представим мы - это ANSI. Как бы дОлжено изменить формулировки в отношении ILs. И что самое главное - как после этого будут выглядеть участники рынка БД?
Видимо нужно прописать все вновь открытые феномены (пришло сразу в голову - потерянные апдейты, но оказалась они уже были известны Дейту в 80х). Надо посмотреть вновь статью и определить какие новые феномены были открыты. Далее, добавить CS? Или заменить RC на CS? Оракл начинает испытывать проблемы с идентификацией в стандарте.
Наверное дать толкование блокировочникам и версионникам, а также ввести уровень SI для версионников будет оптимальным изменением стандарта? Опять Ораклу придется менять доки и переучивать своих последователей.
Что делать-то, Tengiz?

[tengiz]

Как бы дОлжено изменить формулировки в отношении ILs. И что самое главное - как после этого будут выглядеть участники рынка БД?... Видимо нужно прописать все вновь открытые феномены (пришло сразу в голову - потерянные апдейты, но оказалась они уже были известны Дейту в 80х). Надо посмотреть вновь статью и определить какие новые феномены были открыты.

Стандарт - это попытка найти общий знаменатель. И именно в этом смысле стандарт в части уровней изоляции устарел, что приводит к сложностям при переводе приложений БД с одних систем на другие, так как непонятно, как уровни изоляции разных продуктов соотносятся друг с другом. Что касается переформулировки определений, связанных с изоляцией - ну так это ровно то, о чём эта статья. Или я просто не понимаю, о чём Вы говорите?

Далее, добавить CS? Или заменить RC на CS? Оракл начинает испытывать проблемы с идентификацией в стандарте... Наверное дать толкование блокировочникам и версионникам, а также ввести уровень SI для версионников будет оптимальным изменением стандарта? Опять Ораклу придется менять доки и переучивать своих последователей.

Да нет, не начнёт. Это почему вдруг? Оракловский SERIALIZABLE - это и есть SNAPSHOT в чистом виде. Если дырка в стандарте, позволившая ORACLE именовать это уровень SERIALIZABLE, наконец закроется, то ничего страшного не произойдёт. В доках они честно писали и пишут, что их SERIALIZABLE отвечает одному из определений ANSI (гарантирует остутствие всех феноменов, описанных в стандарте), но не отвечает альтернативному определению в том же ANSI, а также тому самому главному, принятому в формальной теории. Поэтому в их доках с незапамятных времён есть рекомендации о том, когда и как нужно применять трюки с искусственными конфликами записи, SELECT FOR UPDATE и ручными блокировками. Не все их правда внимательно читают... Но, винить за это ORACLE уже не совсем правильно.

Что делать-то, Tengiz?

А как же насчёт "кто виноват"?

P.S.

...представим мы - это ANSI.

Да у меня в чуть ли не в кабинетах по соседству члены ANSI SQL комитета сидят, так что...

[tengiz]

Оракловский SERIALIZABLE - это и есть SNAPSHOT в чистом виде. Если дырка в стандарте, позволившая ORACLE именовать это уровень SERIALIZABLE, наконец закроется, то ничего страшного не произойдёт.

Oops! - Эта конкретная дырка в стандарте уже закрыта в SQL99 и неоднозначного толкования SERIALIZABLE уже нет.

<added>

"The exclusion of these phenomena for SQL-transactions executing at isolation level SERIALIZABLE is a consequence of the requirement that such transactions be serializable."

А также и дырка, связанная с P4. Хоть понятие феномена P4 ("Lost updates") отсутствует в SQL99, в тексте документа, тем не менее, специально оговаривается, что "The four isolation levels guarantee that each SQL-transaction will be executed completely or not at all, and that no updates will be lost." Поэтому как ни крути, IBM CS вполне официально и реально тождественно теперешнему ANSI READ COMMITTED.

</added>