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

Откуда: 127.0.0.1
Сообщений: 67534
Блог
mikron
Почему вам serailzable не подходит? Мне концепция оракл именно здесь кажется очень последовательной и продуманной.

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

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

Это не решение. Когда у Вас подтекает бачок в туалете (приложение создаёт ошибочные ситуации), проблема решается фиксингом бачка (исправлением багов в приложении), а не установкой в туалет ведра со шваброй (перезапуском транзакции).
6 дек 13, 14:02    [15252962]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
mikron
Member

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

Вы говорите про "стандартное" поведение REPEATABLE READ. У Оракла стандартно READ COMMITED. Он ведёт себя так как вы описали. следуюший уровень SERIALIZABLE - так как вы хотите.
6 дек 13, 14:05    [15252999]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
softwarer
2. Ничто, они, собственно, так и делают. Попробуйте воспроизвести свой пример в Oracle на уровне изоляции выше read committed, и Вас ожидает сюрприз :)


Так ожидает или нет? А то тут 2 ветви дискуссии и в одной точно все уверены что нет.
6 дек 13, 14:51    [15253417]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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

я немного потерял нить дискусси. Вы спросить хотите или доказать что оракл - недо(-делка, -стандарт, ...)? У оракла нету того что вы там ищите. Есть или меншее или большее. Обоснуйте, зачем вам нужно это промежуточное.
Почему вам serailzable не подходит? Мне концепция оракл именно здесь кажется очень последовательной и продуманной.


Ну хотелось бы repeatable read но без поиска фантомов (так как это не всегда нужный overkill). Хотя возможно вы и правы, или все (serializable) или ничего (read commited). Просто смысла в repeatable read в текущей редакции oracle, ИМХО немного.
6 дек 13, 14:55    [15253462]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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

Это не решение. Когда у Вас подтекает бачок в туалете (приложение создаёт ошибочные ситуации), проблема решается фиксингом бачка (исправлением багов в приложении), а не установкой в туалет ведра со шваброй (перезапуском транзакции).


Здесь не черное и белое, как я уже говорил. Здесь вопрос в компромиссе между производительностью и целостностью. И REPEATABLE READ в среднем (!) лучше всего для этого подходит.

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

И не факт что его вообще можно починить.
6 дек 13, 14:58    [15253491]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Nitro_Junkie
softwarer
2. Ничто, они, собственно, так и делают. Попробуйте воспроизвести свой пример в Oracle на уровне изоляции выше read committed, и Вас ожидает сюрприз :)


Так ожидает или нет? А то тут 2 ветви дискуссии и в одной точно все уверены что нет.

Никто не мешает набрать несколько строк SQL-я и увидеть.
6 дек 13, 15:01    [15253527]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
mikron
Member

Откуда:
Сообщений: 888
Nitro_Junkie
но без поиска фантомов (так как это не всегда нужный overkill). Просто смысла в repeatable read в текущей редакции oracle, ИМХО немного.

Для блокировочников поиск фантомов - дополнителная нагрузка.
Для оракла (версионника) эмуляция блокировочников и включение фантомов в REPEATABLE READ - дополнителная нагрузка. Кому это нужно?
6 дек 13, 15:48    [15254049]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
Для блокировочников поиск фантомов - дополнителная нагрузка.

а пацаны то и не знают. пацаны просто предикаты блокируют.
6 дек 13, 18:31    [15255297]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Yo.!
Guest
Nitro_Junkie
Здесь не черное и белое, как я уже говорил. Здесь вопрос в компромиссе между производительностью и целостностью. И REPEATABLE READ в среднем (!) лучше всего для этого подходит.

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

Откуда:
Сообщений: 11578
Yo.!
майкрософт...слизывать с оракла всю концепцию версионного механизма.
Полный неадекват
6 дек 13, 23:41    [15256391]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Yo.!
Nitro_Junkie
Здесь не черное и белое, как я уже говорил. Здесь вопрос в компромиссе между производительностью и целостностью. И REPEATABLE READ в среднем (!) лучше всего для этого подходит.

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


А причем тут блокировки? REPEATABLE READ и с update conflict (как в postgres и firebird) может реализовываться. И строго гря update conflict'ы чаще чем deadlock'и. В любом случае просто "забить" как это предлагает оракл в его интерпретации REPEATABLE READ еще более идиотское решение.
7 дек 13, 01:29    [15256712]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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

И кстати гря слизали они REPEATABLE READ с Postgres и Firebird, а не Oracle.
7 дек 13, 01:32    [15256721]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
Nitro_Junkie
Nitro_Junkie, ...

Да фиг с ней, с пятницей. Желаю тебе весело провести выходные в кругу друзей )
7 дек 13, 01:46    [15256753]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Yo.!
Guest
[quot hvladПолный неадекват[/quot]
неадекват тут только ты, лабающий код не имея базовых знаний.

Nitro_Junkie
И кстати гря слизали они REPEATABLE READ с Postgres и Firebird, а не Oracle.

кстати говоря ты зря надуваешь щечки не имея элементарных знаний. во первых Firebird не умеет и половины того, что делает на версионных режимах мсскл (у ФБ нет версионного RC), во вторых мсскл как и оракл не смешивает данные и версии строк в одной структуре, что совершенно не похоже на FB/Postgres где версии перемешены с актуальными данными, со всеми вытекающими для перфоменса
7 дек 13, 01:52    [15256765]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
hvlad
Member

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

И кстати гря слизали они REPEATABLE READ с Postgres и Firebird, а не Oracle.
Именно
7 дек 13, 02:07    [15256796]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Dimitry Sibiryakov
Member

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

hvlad
Именно

Если не считать одной мелочи: Firebird-овский уровень изоляции по фамилии concurency
гораздо выше стандартного repeatable read, который обеспечивает повторяемость только в
пределах одного курсора.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 1090
В общем, немного глубже изучив вопрос претензии к Oracle снимаются, у остальных серверов (и по стандарту) фактически разница между REPEATABLE READ и SERIALIZABLE не сильно отличаются (правда все равно нахрена oracle сделал такой странный REPEATABLE READ непонятно), так что у oracle можно просто юзать SERIALIZABLE, и будет почти тоже самое что у остальных.

Но возник другой вопрос. Как уже отмечалось в многопользовательской среде есть фактически 2 стратегии :
1. пессимистичная - при высокой конкурентности и оверхедом на блокировки
2. оптимистичная - при низкой конкурентности и необходимостью заново перезапускать транзакции при конфликте

Но в реальной жизни мир не черно-белый - для большинства данных (особенно справочных) естественно низкая конкурентность и блокировки будут overkill'ом (соответственно логично использовать REPEATABLE READ или SERIALIZABLE), в то же время в одной транзакции часть агрегированных данных могут быть высококонкурентными, как правило остатки, или например общий оборот по юрлицу (был у нас клиент который для оптимизации налогов, хотел иметь ограничение по обороту, и когда оно превышалось, хотел торговать по другой кассе). Соответственно что делать в этом случае непонятно. SELECT FOR UPDATE тут никак не поможет, потому как если с начала транзакции кто-то применит изменение на эти высококонкурентные данные (что очень вероятно), получится update conflict (учитываем что по умолчанию пессимистичный сценарий и соответствующий уровень изоляции). Единственное если переместить SELECT FOR UPDATE в самое начало, но тогда транзакции пойдут совсем последовательно, что мягко гря тоже не вариант.

Что хотелось бы - это чтобы малая часть данных работали как у блокировочника (то есть читали не на начало транзакции, а на текущий момент с S-блокировкой), остальная же часть как у версионника (тут даже не критично читать на начало транзакции, главное проверять на update conflict). Так можно было бы ИМХО гарантировать максимальную параллельность (производительность), при достаточно небольших вероятностях нарушения целостности. Но я так понимаю так никто не умеет :(.
9 дек 13, 12:35    [15263849]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

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

Кстати я так понимаю в SERIALIZABLE транзакции, даже UPDATE одним запросом не поможет, то есть если внутри двух долгих "параллельных" транзакций, сделают:

UPDATE t SET a=a+2 WHERE key =5, UPDATE t SET a=a+4 WHERE key =5, сумма не увеличится на 6, а одна из транзакций откатится с update conflict'ом. Или я ошибаюсь?
9 дек 13, 12:41    [15263907]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Dimitry Sibiryakov
Member

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

Nitro_Junkie
нахрена oracle сделал такой странный REPEATABLE READ

Где сделал? У Оракула нет REPEATABLE READ.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 1090
Dimitry Sibiryakov
Nitro_Junkie
нахрена oracle сделал такой странный REPEATABLE READ

Где сделал? У Оракула нет REPEATABLE READ.


Ну, формально есть (он так называется у них). Просто работает, не как нормальный REPEATABLE READ. Но зато у них есть SERIALIZABLE, который покрывает возможности нормального REPEATABLE READ.
9 дек 13, 14:22    [15264729]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Dimitry Sibiryakov
Member

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

Nitro_Junkie
Ну, формально есть (он так называется у них).

Не знаю что там "формально", но для транзакции в Оракуле можно установить следующие уровни
изоляции: READ COMMITTED, READ ONLY, SERIALIZABLE. Всё, список окончен. Никакого
REPEATABLE READ в нём нет.

Posted via ActualForum NNTP Server 1.5

9 дек 13, 15:12    [15265079]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Сергей Арсеньев
Member

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


Дано У Иванова есть 100 долларов.

1 транзакция - меняет Иванова на Петрова.
2 - списывает у Петрова 10 долларов.

Вопрос - должна ли транзакция молча списывать 10 долларов не у того?
10 дек 13, 13:32    [15270837]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Ivan Durak
Member

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


Дано У Иванова есть 100 долларов.

1 транзакция - меняет Иванова на Петрова.
2 - списывает у Петрова 10 долларов.

Вопрос - должна ли транзакция молча списывать 10 долларов не у того?

ты сначала докажи что не у того????
В этом примере как раз у того! :)
10 дек 13, 15:09    [15271853]     Ответить | Цитировать Сообщить модератору
 Re: Конфликт записи \ чтения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
В общем-то единственное что раскопал, это то что в MS SQL, можно хинтами отдельные таблицы читать READCOMMITED, и при помощи этих же хинтов, вешать соответствующие блокировки. Но с другой стороны, если транзакция будет в "версионном" режиме то update conflict она кинет в любом случае :(

Как говорят в таких случаях, пичалька :(
10 дек 13, 20:31    [15273778]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить