Dimitry SibiryakovNitro_JunkieА если серьезно?
Отрывают руки тем, кто пишет "а=5" вместо "а=а+2".


А если мне нужно какую то более сложную обработку, которая в один запрос не укладывается сделать? Или по их мнению таких не бывает?

DarkMasterNitro_Junkie,

В процедуру оберни - она тоже внутри транзакции крутится.

Причем тут процедура? если у меня одним запросом читается, а вторым пишется (с учетом считанных данных), как в примере, чем это мне поможет? У меня и так все "в транзакции".

Dimitry SibiryakovNitro_JunkieИли по их мнению таких не бывает?
Именно так. Потому вопрос "как сделать ХХХХ одним запросом" так часто задаётся.


Ясно. "Мы успешно решаем проблемы, которые сами себе создаем".

MasterZivNitro_Junkie,

Итак что будут делать (по умолчанию (!)) с repeatable read каждая из СУБД:

Описанная тобой транзакция должна работать на уровне 0, меньше read uncommitted, поэтому что это модификация данных, и если данные при чтении не блокировать, то будет worm hole на любом уровне изоляции.

То, что ты описал, есть как раз тривиальный случай несериализуемой транзакции, как раз и описывающей минимальный уровень изоляции 0, который все субд должны поддерживать.

Рекомендую кстати почитать про теме статью незабвенного Грея и его коллег, под названием «критика уровней изоляции транзакций ANSI».
Статья есть в интернете и на русском тоже, на citforum точно валяется.

Статья хороша тем, что коротка, но сразу вправляет человеку мозги в этом о отношении раз и навсегда.

Статья неплохая, но непонятно что она меняет. Да я понимаю, что в СУБД, идет компромисс между :
1. Производительностью (параллельностью)
2. Целостностью (последовательностью)
Они предлагают расширить уровни изоляции и виды ошибок, ок не вопрос.

Но по их предлагаемой классификации в таблице 4 у Oracle'а когда ставится REPEATABLE READ на самом деле работает условно SNAPSHOT ISOLATION, остальные же СУБД реально работают в REPEATABLE READ. Вопрос какого хрена они не сделали это хотя бы опционально? Это же не сложно.

А то что скажем термин REPEATABLE READ не удачный, что СУБД его трактуют по разному (точнее одно СУБД называемое Oracle), и что можно ввести еще несколько уровней и точнее определить блокировки это понятно. Просто непонятно нахрена такая детализация нужна?
Сейчас READ UNCOMMITED - NoSQL, READ COMMITED - целостность в рамках транзакции на совести разработчика (крутись как хочешь), REPEATABLE READ - целостность в 95%, SERIALIZABLE - целостность в 99.99 (а может 100), только очень четко должно быть все спроектировано, чтобы по производительности вытянуло.

Уровень SNAPSHOT ISOLATION - видимо нужен специально для Oracle. А CURSOR STABILITY только для курсоров которые далеко не все используют (и вообще немного из другой оперы так как вводит доп абстракцию курсоры, я так могу ввести еще абстракцию сервер приложений и еще с десяток уровней изоляции придумать).

Про уровень 0 не понял. Это же даже по их классификации грязнее чтения чем просто Dirty Read, причем тут он?

mikronNitro_Junkie,

Как бы надуманная проблема для Оракла. Можно написат.
UPDATE account SET sum = 5 WHERE key = 5 AND sum = 3

Что, серьезно поможет? В каком уровне изоляции REPEATABLE READ?

softwarerNitro_JunkieНо по их предлагаемой классификации в таблице 4 у Oracle'а когда ставится REPEATABLE READ на самом деле работает условно SNAPSHOT ISOLATION, остальные же СУБД реально работают в REPEATABLE READ. Вопрос какого хрена они не сделали это хотя бы опционально? Это же не сложно. А то что скажем термин REPEATABLE READ не удачный, что СУБД его трактуют по разному (точнее одно СУБД называемое Oracle),
К сожалению, в мире полно идиотов, и для того, чтобы ими управлять, принимаются "политические" решения. Одним из таких политических вопросов являются стандарты ANSI и следование им. Вопрос "СУБД такая-то поддерживает стандарт ANSI SQL такой-то" является политическим; не меняя ничего важного, он многое меняет в решениях, которые принимают идиоты. Поэтому в СУБД делаются различные дурацкие движения для якобы поддержки стандарта, и когда принимаются стандарты, бушуют войны на тему "как бы сформулировать стандарт так, чтобы мы его поддерживали, а конкуренты - нет". В результате появляются мертворождённые уродцы, согласно которым куча существующих СУБД одинаково хреново, но поддерживает этот бессмысленный "стандарт".

Я это понимаю, и в чем то согласен. Но млин Oracle там настроек делает вагон и маленькую тележку, что им мешает просто при update'е сверить версию записи с версией начала транзакции и если она больше кинуть exception. Я же не автоматический блокировочник от них хочу, а одну маленькую штуку которая с очень большой вероятностью обеспечит мне поддержку одного из самых популярных конфликтов.

MasterZivNitro_Junkie,

Про уровень 0 не понял. Это же даже по их классификации грязнее чтения чем просто Dirty Read, причем тут он?


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

Я также не понял, что ты в итоге хочешь, понять уровни изоляции, или разобраться , как решать проблему в том конкретном случае, который ты привел.

И как мне минимальный уровень изоляции поможет решить проблему, которую я привел?

SELECT FOR UPDATE расставлять? Так это я с любым уровнем изоляции могу делать (даже READ COMMITED).

mikronNitro_JunkieЧто, серьезно поможет? В каком уровне изоляции REPEATABLE READ?
для READ COMMITTED а для SERIALIZABLE уже не нужно. А других уровней у оракла (10.2) я не знаю.

Так в приведенном случае с READ COMMITED она сначала запишет 5, а во втором ничего не запишет, и останется 5, что тоже неправильно. Или предполагается ловить rows updated и если там 0 то самому "кидать" exception. Так это ручной режим, я его могу и timestamp'ами (как и у блокировочников) решить, просто можно заколебаться это делать в каждом случае.

MasterZivЭта проблема, описанная тобой, никакими другими уровнями изоляции не решается.


Разве она не решается в 95% (а то и 100) установкой REPEATABLE READ в MSSQL (в обоих режимах), Postgres, Firebird и т.п. и перепроведением транзакции при deadlock \ update conflict'е ?

Leonid KudryavtsevНО большинство средств разработки так и поступают (например Oracle Forms, ряд ООП оберток над БД). Т.ч. обычно проблем с этим нет.

Там только в ORM проблем нет, как только начинаешь чистый SQL юзать, те же яйца. Только не надо говорит не юзайте SQL, я даже это обсуждать не буду :)

Leonid KudryavtsevТо, что сервер выдал exception, в любом случае никак не спасет - этот exception еще как-то *вменяемо* обработать нужно.
Очень даже спасет во многих случаях, я просто перезапущу транзакцию (причем могу это даже сделать невидимо для пользователя).

Позвоните Ларри, предложите ему денег. Он попросит программистов реализовать ))). Все зависит от Вас (точнее Ваших финансовых возможностей) )))

Спасибо, но я лучше тогда вместо оракла, mssql юзать (предлагать) буду, переплачивать хрен знает сколько и получать такую проблему на ровном месте. :(

MasterZivNitro_JunkieЯ это понимаю, и в чем то согласен. Но млин Oracle там настроек делает вагон и маленькую тележку, что им мешает просто при update'е сверить версию записи с версией начала транзакции и если она больше кинуть exception. Я же не автоматический блокировочник от них хочу, а одну маленькую штуку которая с очень большой вероятностью обеспечит мне поддержку одного из самых популярных конфликтов.

Э.. ммм... А если вы всё же РАЗНЫЕ поля данной записи будете менять ?
Версии будут разные, получишь ты exception, транзакцию откатишь, и всё зря ?

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