Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Dimitry Sibiryakov
Nitro_Junkie
А если серьезно?

Отрывают руки тем, кто пишет "а=5" вместо "а=а+2".


А если мне нужно какую то более сложную обработку, которая в один запрос не укладывается сделать? Или по их мнению таких не бывает?
5 дек 13, 19:14    [15248874]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
DarkMaster
Member

Откуда: Donetsk,Ukraine
Сообщений: 6572
Nitro_Junkie,

В процедуру оберни - она тоже внутри транзакции крутится.
5 дек 13, 19:26    [15248918]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
DarkMaster
Nitro_Junkie,

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


Причем тут процедура? если у меня одним запросом читается, а вторым пишется (с учетом считанных данных), как в примере, чем это мне поможет? У меня и так все "в транзакции".
5 дек 13, 19:28    [15248923]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54790

Nitro_Junkie
Или по их мнению таких не бывает?

Именно так. Потому вопрос "как сделать ХХХХ одним запросом" так часто задаётся.

Posted via ActualForum NNTP Server 1.5

5 дек 13, 19:49    [15249021]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Dimitry Sibiryakov
Nitro_Junkie
Или по их мнению таких не бывает?

Именно так. Потому вопрос "как сделать ХХХХ одним запросом" так часто задаётся.


Ясно. "Мы успешно решаем проблемы, которые сами себе создаем".
5 дек 13, 19:54    [15249052]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Nitro_Junkie,

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

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

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

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

Статья хороша тем, что коротка, но сразу вправляет человеку мозги в этом о отношении раз и навсегда.
5 дек 13, 23:23    [15249724]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Nitro_Junkie
ScareCrow
студент учи что такое транзакции,


Очень ценное замечание. Чтобы я без него делал даже не знаю...


Nitro_Junkie, тут трепа будет на 10 страниц вокруг этого, и все будут не правы, и ты кстати уже тоже уцепился на это.
В ANSI SQL нет уровней изоляции, которые позволяли бы решить указанную тобой проблему. В ANSI SQL есть уровни изоляции только для разрешения проблем чтения данных, а твой пример — пример 2х транзакций записи.

А ты уже пустился в рассуждения о том, Как же будут себя вести разные субд на этих уровнях. Да никак, те уровни — о другом.

А про select for update — да, он обязан там быть, и это правильное и единственное решение, причем оно на всех субд одинаково .
5 дек 13, 23:33    [15249756]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
mikron
Member

Откуда:
Сообщений: 888
Nitro_Junkie,

Как бы надуманная проблема для Оракла. Можно написат.
UPDATE account SET sum = 5 WHERE key = 5 AND sum = 3
6 дек 13, 01:35    [15250129]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
MasterZiv
Nitro_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, причем тут он?
6 дек 13, 12:20    [15251973]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
mikron
Nitro_Junkie,

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


Что, серьезно поможет? В каком уровне изоляции REPEATABLE READ?
6 дек 13, 12:22    [15251981]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Nitro_Junkie,

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


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

Я также не понял, что ты в итоге хочешь, понять уровни изоляции, или разобраться , как решать проблему в том конкретном случае, который ты привел.
6 дек 13, 12:45    [15252170]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
softwarer
Member

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

К сожалению, в мире полно идиотов, и для того, чтобы ими управлять, принимаются "политические" решения. Одним из таких политических вопросов являются стандарты ANSI и следование им. Вопрос "СУБД такая-то поддерживает стандарт ANSI SQL такой-то" является политическим; не меняя ничего важного, он многое меняет в решениях, которые принимают идиоты. Поэтому в СУБД делаются различные дурацкие движения для якобы поддержки стандарта, и когда принимаются стандарты, бушуют войны на тему "как бы сформулировать стандарт так, чтобы мы его поддерживали, а конкуренты - нет". В результате появляются мертворождённые уродцы, согласно которым куча существующих СУБД одинаково хреново, но поддерживает этот бессмысленный "стандарт".
6 дек 13, 12:47    [15252195]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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

К сожалению, в мире полно идиотов, и для того, чтобы ими управлять, принимаются "политические" решения. Одним из таких политических вопросов являются стандарты ANSI и следование им. Вопрос "СУБД такая-то поддерживает стандарт ANSI SQL такой-то" является политическим; не меняя ничего важного, он многое меняет в решениях, которые принимают идиоты. Поэтому в СУБД делаются различные дурацкие движения для якобы поддержки стандарта, и когда принимаются стандарты, бушуют войны на тему "как бы сформулировать стандарт так, чтобы мы его поддерживали, а конкуренты - нет". В результате появляются мертворождённые уродцы, согласно которым куча существующих СУБД одинаково хреново, но поддерживает этот бессмысленный "стандарт".


Я это понимаю, и в чем то согласен. Но млин Oracle там настроек делает вагон и маленькую тележку, что им мешает просто при update'е сверить версию записи с версией начала транзакции и если она больше кинуть exception. Я же не автоматический блокировочник от них хочу, а одну маленькую штуку которая с очень большой вероятностью обеспечит мне поддержку одного из самых популярных конфликтов.
6 дек 13, 12:58    [15252315]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
mikron
Member

Откуда:
Сообщений: 888
Nitro_Junkie
Что, серьезно поможет? В каком уровне изоляции REPEATABLE READ?

для READ COMMITTED а для SERIALIZABLE уже не нужно. А других уровней у оракла (10.2) я не знаю.
6 дек 13, 12:58    [15252321]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
MasterZiv
Nitro_Junkie,

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


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

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


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

SELECT FOR UPDATE расставлять? Так это я с любым уровнем изоляции могу делать (даже READ COMMITED).
6 дек 13, 13:00    [15252339]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
mikron
Nitro_Junkie
Что, серьезно поможет? В каком уровне изоляции REPEATABLE READ?

для READ COMMITTED а для SERIALIZABLE уже не нужно. А других уровней у оракла (10.2) я не знаю.


Так в приведенном случае с READ COMMITED она сначала запишет 5, а во втором ничего не запишет, и останется 5, что тоже неправильно. Или предполагается ловить rows updated и если там 0 то самому "кидать" exception. Так это ручной режим, я его могу и timestamp'ами (как и у блокировочников) решить, просто можно заколебаться это делать в каждом случае.
6 дек 13, 13:04    [15252373]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Nitro_Junkie

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

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


Опять ты ничего не понял.
SELECT FOR UPDATE и есть этот минимальный уровень изоляции. И никакие другие уровни уже тут ни при чём.
И кроме расстановки FOR UPDATE в SELECT-ы никакие другие уровни изоляции не помогут, и не нужны.

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

Понял ?
6 дек 13, 13:26    [15252601]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9882
Раньше был такой продукт MS FoxPro, там было два класса методов блокировок:

пессимистическая блокировка
оптимистическая блокировка

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

То, что сервер выдал exception, в любом случае никак не спасет - этот exception еще как-то *вменяемо* обработать нужно.

IMHO & AFAIK

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

Позвоните Ларри, предложите ему денег. Он попросит программистов реализовать ))). Все зависит от Вас (точнее Ваших финансовых возможностей) )))
6 дек 13, 13:28    [15252617]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
MasterZiv,

", и не нужны." -- для этого случая, я имел в виду, естественно.
6 дек 13, 13:30    [15252634]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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


Разве она не решается в 95% (а то и 100) установкой REPEATABLE READ в MSSQL (в обоих режимах), Postgres, Firebird и т.п. и перепроведением транзакции при deadlock \ update conflict'е ?
6 дек 13, 13:32    [15252661]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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


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

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

Очень даже спасет во многих случаях, я просто перезапущу транзакцию (причем могу это даже сделать невидимо для пользователя).

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


Спасибо, но я лучше тогда вместо оракла, mssql юзать (предлагать) буду, переплачивать хрен знает сколько и получать такую проблему на ровном месте. :(
6 дек 13, 13:36    [15252700]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
MasterZiv
Member

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


Э.. ммм... А если вы всё же РАЗНЫЕ поля данной записи будете менять ?
Версии будут разные, получишь ты exception, транзакцию откатишь, и всё зря ?
6 дек 13, 13:46    [15252817]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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


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


Ну конечно круче было бы если по колонкам проверял, но и по записям сойдет.
6 дек 13, 13:50    [15252859]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Nitro_Junkie
Я это понимаю, и в чем то согласен. Но млин Oracle там настроек делает вагон и маленькую тележку, что им мешает просто при update'е сверить версию записи с версией начала транзакции

1. Во-первых, регулировать подобное поведение настройками - худшее возможное решение. С этим в MSSQL, пожалуйста, хотя и там от этого стараются уйти

2. Ничто, они, собственно, так и делают. Попробуйте воспроизвести свой пример в Oracle на уровне изоляции выше read committed, и Вас ожидает сюрприз :)
6 дек 13, 13:57    [15252911]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
mikron
Member

Откуда:
Сообщений: 888
Nitro_Junkie,

я немного потерял нить дискусси. Вы спросить хотите или доказать что оракл - недо(-делка, -стандарт, ...)? У оракла нету того что вы там ищите. Есть или меншее или большее. Обоснуйте, зачем вам нужно это промежуточное.
Почему вам serailzable не подходит? Мне концепция оракл именно здесь кажется очень последовательной и продуманной.
6 дек 13, 13:57    [15252915]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить