powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Конфликт записи \ чтения
25 сообщений из 101, страница 3 из 5
Конфликт записи \ чтения
    #38491758
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronПочему вам serailzable не подходит? Мне концепция оракл именно здесь кажется очень последовательной и продуманной.
Она последовательна и продуманна, она просто не везде хорошо ложится на другую концепцию, придуманную для блокировочников. По-хорошему, следовало бы не пудрить людям мозги, но политика требует называть одинаковыми словами и говорить "мы поддерживаем".
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491763
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieРазве она не решается в 95% (а то и 100) установкой REPEATABLE READ в MSSQL (в обоих режимах), Postgres, Firebird и т.п. и перепроведением транзакции при deadlock \ update conflict'е ?
Это не решение. Когда у Вас подтекает бачок в туалете (приложение создаёт ошибочные ситуации), проблема решается фиксингом бачка (исправлением багов в приложении), а не установкой в туалет ведра со шваброй (перезапуском транзакции).
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491773
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkie,

Вы говорите про "стандартное" поведение REPEATABLE READ. У Оракла стандартно READ COMMITED. Он ведёт себя так как вы описали. следуюший уровень SERIALIZABLE - так как вы хотите.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491880
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer2. Ничто, они, собственно, так и делают. Попробуйте воспроизвести свой пример в Oracle на уровне изоляции выше read committed, и Вас ожидает сюрприз :)

Так ожидает или нет? А то тут 2 ветви дискуссии и в одной точно все уверены что нет.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491892
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mikronNitro_Junkie,

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

Ну хотелось бы repeatable read но без поиска фантомов (так как это не всегда нужный overkill). Хотя возможно вы и правы, или все (serializable) или ничего (read commited). Просто смысла в repeatable read в текущей редакции oracle, ИМХО немного.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491896
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerNitro_JunkieРазве она не решается в 95% (а то и 100) установкой REPEATABLE READ в MSSQL (в обоих режимах), Postgres, Firebird и т.п. и перепроведением транзакции при deadlock \ update conflict'е ?
Это не решение. Когда у Вас подтекает бачок в туалете (приложение создаёт ошибочные ситуации), проблема решается фиксингом бачка (исправлением багов в приложении), а не установкой в туалет ведра со шваброй (перезапуском транзакции).

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

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

И не факт что его вообще можно починить.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491905
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkiesoftwarer2. Ничто, они, собственно, так и делают. Попробуйте воспроизвести свой пример в Oracle на уровне изоляции выше read committed, и Вас ожидает сюрприз :)

Так ожидает или нет? А то тут 2 ветви дискуссии и в одной точно все уверены что нет.
Никто не мешает набрать несколько строк SQL-я и увидеть.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38491980
mikron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkieно без поиска фантомов (так как это не всегда нужный overkill). Просто смысла в repeatable read в текущей редакции oracle, ИМХО немного.
Для блокировочников поиск фантомов - дополнителная нагрузка.
Для оракла (версионника) эмуляция блокировочников и включение фантомов в REPEATABLE READ - дополнителная нагрузка. Кому это нужно?
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492270
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторДля блокировочников поиск фантомов - дополнителная нагрузка.
а пацаны то и не знают. пацаны просто предикаты блокируют.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492470
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Nitro_JunkieЗдесь не черное и белое, как я уже говорил. Здесь вопрос в компромиссе между производительностью и целостностью. И REPEATABLE READ в среднем (!) лучше всего для этого подходит.

и особенно хорошо он подходит, что бы поставить систему раком.
блокировки на любой чих просто задушат систему дедлоками. майкрософт долго подалась но факты были столь неумолимы, что пришлось признать, что версионный механизм гораздо лучше справляется с тяжелым OLTP и слизывать с оракла всю концепцию версионного механизма.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492492
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!майкрософт...слизывать с оракла всю концепцию версионного механизма.Полный неадекват
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492532
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!Nitro_JunkieЗдесь не черное и белое, как я уже говорил. Здесь вопрос в компромиссе между производительностью и целостностью. И REPEATABLE READ в среднем (!) лучше всего для этого подходит.

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

А причем тут блокировки? REPEATABLE READ и с update conflict (как в postgres и firebird) может реализовываться. И строго гря update conflict'ы чаще чем deadlock'и. В любом случае просто "забить" как это предлагает оракл в его интерпретации REPEATABLE READ еще более идиотское решение.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492534
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkie,

И кстати гря слизали они REPEATABLE READ с Postgres и Firebird, а не Oracle.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492538
Зайцев Фёдор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieNitro_Junkie, ...
Да фиг с ней, с пятницей. Желаю тебе весело провести выходные в кругу друзей )
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492540
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
[quot hvladПолный неадекват[/quot]
неадекват тут только ты, лабающий код не имея базовых знаний.

Nitro_JunkieИ кстати гря слизали они REPEATABLE READ с Postgres и Firebird, а не Oracle.
кстати говоря ты зря надуваешь щечки не имея элементарных знаний. во первых Firebird не умеет и половины того, что делает на версионных режимах мсскл (у ФБ нет версионного RC), во вторых мсскл как и оракл не смешивает данные и версии строк в одной структуре, что совершенно не похоже на FB/Postgres где версии перемешены с актуальными данными, со всеми вытекающими для перфоменса
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492541
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieNitro_Junkie,

И кстати гря слизали они REPEATABLE READ с Postgres и Firebird, а не Oracle.Именно
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38492551
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladИменно
Если не считать одной мелочи: Firebird-овский уровень изоляции по фамилии concurency
гораздо выше стандартного repeatable read, который обеспечивает повторяемость только в
пределах одного курсора.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38493928
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем, немного глубже изучив вопрос претензии к 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). Так можно было бы ИМХО гарантировать максимальную параллельность (производительность), при достаточно небольших вероятностях нарушения целостности. Но я так понимаю так никто не умеет :(.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38493939
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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'ом. Или я ошибаюсь?
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38494056
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkieнахрена oracle сделал такой странный REPEATABLE READ
Где сделал? У Оракула нет REPEATABLE READ.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38494093
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNitro_Junkieнахрена oracle сделал такой странный REPEATABLE READ
Где сделал? У Оракула нет REPEATABLE READ.


Ну, формально есть (он так называется у них). Просто работает, не как нормальный REPEATABLE READ. Но зато у них есть SERIALIZABLE, который покрывает возможности нормального REPEATABLE READ.
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38494177
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieНу, формально есть (он так называется у них).
Не знаю что там "формально", но для транзакции в Оракуле можно установить следующие уровни
изоляции: READ COMMITTED, READ ONLY, SERIALIZABLE. Всё, список окончен. Никакого
REPEATABLE READ в нём нет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38495464
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЭ.. ммм... А если вы всё же РАЗНЫЕ поля данной записи будете менять ?
Версии будут разные, получишь ты exception, транзакцию откатишь, и всё зря ?

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

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

Вопрос - должна ли транзакция молча списывать 10 долларов не у того?
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38495697
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей АрсеньевMasterZivЭ.. ммм... А если вы всё же РАЗНЫЕ поля данной записи будете менять ?
Версии будут разные, получишь ты exception, транзакцию откатишь, и всё зря ?

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

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

Вопрос - должна ли транзакция молча списывать 10 долларов не у того?
ты сначала докажи что не у того????
В этом примере как раз у того! :)
...
Рейтинг: 0 / 0
Конфликт записи \ чтения
    #38496186
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем-то единственное что раскопал, это то что в MS SQL, можно хинтами отдельные таблицы читать READCOMMITED, и при помощи этих же хинтов, вешать соответствующие блокировки. Но с другой стороны, если транзакция будет в "версионном" режиме то update conflict она кинет в любом случае :(

Как говорят в таких случаях, пичалька :(
...
Рейтинг: 0 / 0
25 сообщений из 101, страница 3 из 5
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Конфликт записи \ чтения
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]