История изменений
Исправление byko3y, (текущая версия) :
Я извиняюсь, но не думайте так больше, а почитайте учебник по теории СУБД – это должно быть почти в любом. Нет, изоляция не независима, и является одним из основных свойств СУБД, без которого ACID превращается, максимум, в AD.
Что делать с SQLite, который до реализации WAL вообще не имел изоляции? Я напомню, что в состав ACID не входит понятия «concurrency», потому полностью упорядоченный по изменениям доступ к базе вполне удовлетворяет ACD до тех пор, пока соблюдена атомарность изменений, целостность и сохранность данных. Собсна, сама изоляция - это именно требование к параллельному доступу, но если параллелизации нет - изоляция отваливается.
Определению изоляции (максимально кратко: isolation = serializability) уже более 50 лет, наверное, и никаких дебатов по его поводу нет (и оно же в неизменном виде входит в стандарт SQL ещё с начала 1990-х). А статья совсем не об этом.
Если какая-то СУБД на том уровне изоляции, который в ней называется «serializable», не предоставляет сериализуемости, она грубо нарушает стандарт (и, с учётом того, что определению serializable полвека, и компетентные разработчики СУБД не могут его не знать, ещё и нагло лжёт).
Статья в том числе затрагивает проблему разницы между изоляцией и сериализацией. Сам стандарт, к которому я советую отсылаться [1], дает два дополняющих определения serializable - одно из них определяет изоляцию для этого режима в терминах феномена P3 («Phantom»), второе - определяет совершенно иное требование сериализуемости, ортогональное феноменам нарушения изоляции P1, P2, P3. Oracle в своем «serializable» выполняет отсутствие феноменов P1, P2, P3, как того требует стандарт, но не выполняет требование сериализуемости, таким образом соответствуя режиму «ANOMALY SERIALIZABLE» из статьи.
Таким образом, здесь можно увидеть два независимых требования к системе: изоляция и сериализация - которые с легкой ноги коммитета ANSI были запихнуты в одно понятие «изоляция».
[1] http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Firebird/Interbase, например, имеет настоящую сериализацию, которая бы в последнем примере вместо двух нулей вставила 0 и 1.
Тоже не имеет, кстати. См. http://www.bailis.org/blog/when-is-acid-acid-rarely/ про реальные «достижения» современных СУБД на этом поприще.
Вот я тут сижу теперь и думаю «то ли я верблюд, то ли...». Пошел и проверил взаимные insert...select:
> Insert into T2 (ID) select ID from T1> Insert into T1 (ID) select ID from T2
lock conflict on no wait transaction
Acquire lock for relation (t2) failedИсходная версия byko3y, :
Я извиняюсь, но не думайте так больше, а почитайте учебник по теории СУБД – это должно быть почти в любом. Нет, изоляция не независима, и является одним из основных свойств СУБД, без которого ACID превращается, максимум, в AD.
Что делать с SQLite, который до реализации WAL вообще не имел изоляции? Я напомню, что в состав ACID не входит понятия «concurrency», потому полностью упорядоченный по изменениям доступ к базе вполне удовлетворяет ACD до тех пор, пока соблюдена атомарность изменений, целостность и сохранность данных. Собсна, сама изоляция - это именно требование к параллельному доступу, но если параллелизации нет - изоляция отваливается.
Определению изоляции (максимально кратко: isolation = serializability) уже более 50 лет, наверное, и никаких дебатов по его поводу нет (и оно же в неизменном виде входит в стандарт SQL ещё с начала 1990-х). А статья совсем не об этом.
Если какая-то СУБД на том уровне изоляции, который в ней называется «serializable», не предоставляет сериализуемости, она грубо нарушает стандарт (и, с учётом того, что определению serializable полвека, и компетентные разработчики СУБД не могут его не знать, ещё и нагло лжёт).
Статья в том числе затрагивает проблему разницы между изоляцией и сериализацией. Сам стандарт, к которому я советую отсылаться [1], дает два дополняющих определения serializable - одно из них определяет изоляцию для этого режима в терминах феномена P3 («Phantom»), второе - определяет совершенно иное требование сериализуемости, ортогональное феноменам нарушения изоляции P1, P2, P3. Oracle в своем «serializable» выполняет отсутствие феноменов P1, P2, P3, как того требует стандарт, но не выполняет требование сериализуемости, таким образом соответствуя режиму «ANOMALY SERIALIZABLE» из статьи.
Таким образом, здесь можно увидеть два независимых требования к системе: изоляция и сериализация - которые с легкой ноги коммитета ANSI были запихнуты в одно понятие «изоляция».
[1] http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Эта проблема затрагивается статьей ( https://www.cs.umb.edu/~poneil/iso.pdf ), и я советую в таких случаях читать оригинальный стандарт для того, чтобы понять суть двусмысленности определения стандарта:
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Firebird/Interbase, например, имеет настоящую сериализацию, которая бы в последнем примере вместо двух нулей вставила 0 и 1.
Тоже не имеет, кстати. См. http://www.bailis.org/blog/when-is-acid-acid-rarely/ про реальные «достижения» современных СУБД на этом поприще.
Вот я тут сижу теперь и думаю «то ли я верблюд, то ли...». Пошел и проверил взаимные insert...select:
> Insert into T2 (ID) select ID from T1> Insert into T1 (ID) select ID from T2
lock conflict on no wait transaction
Acquire lock for relation (t2) failed