Здравствуйте, Olaf, Вы писали:

O>Здравствуйте, andyag, Вы писали:

A>>Вопрос номер 1: правильно ли я понимаю, что от СУБД к СУБД нюансы поведения могут отличаться, но несмотря на это, если СУБД заявляет "умею транзакции", есть минимальный набор гарантий, которые обязаны выполняться?
O>То что вы перечислили входит в стандарт ISO. По идее многие производители СУБД стремятся к нему, но не всегда поддерживают на 100%, поэтому не исключаю, что могут быть нюансы.

A>>Я правильно понимаю, что dirty reads и non-repeatable reads действительно относятся только к изменениям на уровне строк, а phantom reads — только к изменениям на уровне таблицы? Т.е. параллельный update может вызвать 1 и 2, но не 3, а параллельный insert/delete — только 3, но не 1 или 2?

O>Мне кажется, что здесь привязка к объектам строка-таблица не очень уместна. Например, грязное чтение вы можете получить, не только на обновлении, но и на вставке и удалении, т.е. когда DML изменения не зафиксированы в другой транзакции.

Вот это интересно. А как тогда однозначно разделить non-repeatable reads и phantom reads?

A>>Теперь про сами уровни изоляции:
A>>...
A>>Насколько верно? Правильно ли я понимаю, что теоретически СУБД может реализовать только уровень serializable и подставлять его вместо всех менее строгих, т.к. serializable их в себя включает?

O>Все написано верно. В теории уровень изоляции serializable покрывает все проблемы описанные вами, но за это приходится расплачиваться снижением уровня конкуренции в БД. Вообще на практике уровень изоляции выбирается из тех задач, которые он помогает решить, а не наоборот. Кроме того в рамках одной БД могут использоваться разные уровни изоляции, опять же в зависимости от задачи. Чтобы со всем этим разобраться мне кажется, нужно взять «любимую СУБД» и рассмотреть реализацию каждого уровня изоляции. Тогда возникнет понимание, а за счет чего именно удается реализовать конкретное поведение (грязное чтение, фантомы и прочее).

Я так и поступаю, просто любимая СУБД оказалась неадекватом в плане изоляции — А помогите пожалуйста с транзакциями в JDBC. Вот теперь хочу уточнить кто из нас двоих неадекват.

Здравствуйте, Olaf, Вы писали:

O>Здравствуйте, andyag, Вы писали:

A>>Я правильно понимаю, что dirty reads и non-repeatable reads действительно относятся только к изменениям на уровне строк, а phantom reads — только к изменениям на уровне таблицы? Т.е. параллельный update может вызвать 1 и 2, но не 3, а параллельный insert/delete — только 3, но не 1 или 2?

O>Мне кажется, что здесь привязка к объектам строка-таблица не очень уместна. Например, грязное чтение вы можете получить, не только на обновлении, но и на вставке и удалении, т.е. когда DML изменения не зафиксированы в другой транзакции.

Вот это интересно. А как тогда однозначно разделить non-repeatable reads и phantom reads?

A>>Теперь про сами уровни изоляции:
A>>...
A>>Насколько верно? Правильно ли я понимаю, что теоретически СУБД может реализовать только уровень serializable и подставлять его вместо всех менее строгих, т.к. serializable их в себя включает?

O>Все написано верно. В теории уровень изоляции serializable покрывает все проблемы описанные вами, но за это приходится расплачиваться снижением уровня конкуренции в БД. Вообще на практике уровень изоляции выбирается из тех задач, которые он помогает решить, а не наоборот. Кроме того в рамках одной БД могут использоваться разные уровни изоляции, опять же в зависимости от задачи. Чтобы со всем этим разобраться мне кажется, нужно взять «любимую СУБД» и рассмотреть реализацию каждого уровня изоляции. Тогда возникнет понимание, а за счет чего именно удается реализовать конкретное поведение (грязное чтение, фантомы и прочее).

Я так и поступаю, просто любимая СУБД оказалась неадекватом в плане изоляции — А помогите пожалуйста с транзакциями в JDBC. Вот теперь хочу уточнить кто из нас двоих неадекват.