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

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

mikronNitro_Junkie,

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

Ну хотелось бы repeatable read но без поиска фантомов (так как это не всегда нужный overkill). Хотя возможно вы и правы, или все (serializable) или ничего (read commited). Просто смысла в repeatable read в текущей редакции oracle, ИМХО немного.

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

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

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

И не факт что его вообще можно починить.

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

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

А причем тут блокировки? REPEATABLE READ и с update conflict (как в postgres и firebird) может реализовываться. И строго гря update conflict'ы чаще чем deadlock'и. В любом случае просто "забить" как это предлагает оракл в его интерпретации REPEATABLE READ еще более идиотское решение.

Nitro_Junkie,

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

В общем, немного глубже изучив вопрос претензии к 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). Так можно было бы ИМХО гарантировать максимальную параллельность (производительность), при достаточно небольших вероятностях нарушения целостности. Но я так понимаю так никто не умеет :(.

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'ом. Или я ошибаюсь?

Dimitry SibiryakovNitro_Junkieнахрена oracle сделал такой странный REPEATABLE READ
Где сделал? У Оракула нет REPEATABLE READ.


Ну, формально есть (он так называется у них). Просто работает, не как нормальный REPEATABLE READ. Но зато у них есть SERIALIZABLE, который покрывает возможности нормального REPEATABLE READ.

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

Как говорят в таких случаях, пичалька :(