Привет, Merle!
Вы пишешь 22 декабря 2005:

AC>> Смотрим сюда.
AC>> Tr1.Start(read_committed, rec_version, nowait)
AC>> Tr2.Start(read_committed, rec_version, nowait)
AC>> Tr1.UpdateSomeRecord
AC>> Tr2.UpdateSomeRecord ==> Lock conflictk on nowait transaction

M> Что в этот момент делает TR2?

НИКУА НЕ ДЕЛАЕТ.
Я как юзер получаю сообщение о конфликте блокировок.
И ВСЁ.
Дальше мне решать, что делать.
А не провайдеру тупорылому.

AC>> Tr1.Commit
AC>> Tr2.UpdateSomeRecord
AC>> Tr2.Commit
AC>> Где откат?

M> Что — нету? Лень искать, но в этом же форуме мне годя два назад доказывали
M> с пеной у рта, что откат-таки будет.

Мне, как юзеру/программеру решать, откатывать ли транзакцию,
либо коммитить, либо попытаться снова.
Это MS вас подсадил на т.н. "автоматическое управление транзакциями".
И вы свято уверены, что по другому и быть не может.

AC>> И поясни убогому про "вплоть до юзера"...

M> Вплоть до юзера это значит что на уровне провайдера происходит exception...

Всё. Дальше не продолжай.
Разговор глухого со слепым...
Смешались в кучу кони, люди... (С)
И сервер со средствами доступа.

Дальнейшую дискуссию считаю нецелесообразной.
Аминь.

--
With best regards, Alex Cherednichenko.

Здравствуйте, Alex.Che, Вы писали:

AC>Я как юзер получаю сообщение о конфликте блокировок.
AC>И ВСЁ.
AC>Дальше мне решать, что делать.
AC>А не провайдеру тупорылому.
Отлично, и возвращаясь к основному предмету спора, ты правда считаешь, что это будет быстрее, чем если сервер разрулит это автоматически?

AC>Мне, как юзеру/программеру решать, откатывать ли транзакцию,
AC>либо коммитить, либо попытаться снова.
Даже при Snapshot? В этом случае ты не сможешь гарантировать отсутствие конфликтов и, собственно snapshot-ность, если сможешь серверу явно указать перезапись чужой версии.

AC>Это MS вас подсадил на т.н. "автоматическое управление транзакциями".
Да нет, как раз наоборот. Это IB взвалил решение об откате на разработчика, а все приличные сервера такой фигней не страдают.

AC>И вы свято уверены, что по другому и быть не может.
Почему, можт, только смысла не имеет.

AC>Дальнейшую дискуссию считаю нецелесообразной.
Еще бы, аргументов-то нет.. )

M>Речь идет о проблемах такого уровня сложности, что бытовой здравый смысл уже не работает.

Допустим, это похоже на правду.

Однако то что микрософт его реализовало говорит о том что они сделали это не для смеха,

или для смеха?

M>Не существует (насколько мне известно) оснований полагать, что версионный подход должен быть более эффективным. Причем не существует ни в теории, ни на практике. Только частные случаи.

M>Очень близкие результаты получаются в реальной жизни.


И никто не проверял что сделано это только для юмора или дает резултаты?

Здравствуйте, Alex.Che, Вы писали:

M>> Что в этот момент делает TR2?

AC>НИКУА НЕ ДЕЛАЕТ.
AC>Я как юзер получаю сообщение о конфликте блокировок.
AC>И ВСЁ.
AC>Дальше мне решать, что делать.
AC>А не провайдеру тупорылому.

Это ты о ком, то есть кому?

Я перед законом чист — ничего такого, за что порвут как грелку, не решаю

AC>Всё. Дальше не продолжай.
AC>Разговор глухого со слепым...
AC>Смешались в кучу кони, люди... (С)

Там еще и Дом Обломова был

AC>Дальнейшую дискуссию считаю нецелесообразной.
Все равно: Firebird — чемпион
AC>Аминь.

Здравствуйте, Merle, Вы писали:

AC>>Это MS вас подсадил на т.н. "автоматическое управление транзакциями".

M>Да нет, как раз наоборот. Это IB взвалил решение об откате на разработчика, а все приличные сервера такой фигней не страдают.



Я одно понять не могу — как мы бедные до сих пор не померли от такой ответственности — явно вызывать start/commit/rollback транзакций.

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

Merle,

AC>> Tr1.Commit
AC>> Tr2.UpdateSomeRecord
AC>> Tr2.Commit
AC>> Где откат?
>
M> Что — нету? Лень искать, но в этом же форуме мне годя
M> два назад доказывали с пеной у рта, что откат-таки будет.

Автоматического отката транзакции не будет никогда. Если кто-то писал обратное — это на его совести. При неразрешенном конфликте всегда будет только откат оператора. Ты про это?

M> Тот же Oracle в такой ситуации,
M> производит откат запроса, а затем выполняет запрос повторно,
M> внутри себя, клиент об этой механике даже не догадывается, но
M> тем не менее это полноценный откат.

Он перевыполняет только конкретную операцию записи (вместе с проверкой предиката) или весь запрос? А в режиме NO WAIT (или какой там у него аналог) он как поступает?

M> теоретически при RC на конфликт версий можно просто забить
M> и писать поверх, что делает MSSQL и, в некоторых ситуациях Oracle
M> (насчет IB/FB вопрос все еще туманный)

В IB/FB перезапись может быть, а может и нет (т.е. откат) — зависит от вида RC транзакции. Кстати, насколько перезапись теоретически правильна для RC — я четкого ответа найти не смог. IMHO, тут все от реализации зависит.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alex.Che, Вы писали:

AC>>О каком многолетнем опыте версионного режима MSSQL-2005 речь?
M>Причем здесь SQL 2005? Я имел ввиду версионный механизм вообще, безотносительно конкретной реализации.

"вообще" иметь в виду версионный механизм странно, потому что он уже есть в
1. InterBase/Firebird, первая коммерческая реализация
2. Oracle, в том или ином виде
3. PostgreSQL (с 1995 года)
4. MS SQL 2005

и планируется (или уже есть) в MySQL.

M>Что касается SQL 2005, то в голой теории это довольно удачная реализация, а о серьезной практике говорить пока рано.

пока будем считать, что это копия с Interbase, а уж удачная или нет — посмотрим.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, vgrigor, Вы писали:

V>>поясните нам почему блокировка — лучше отсутсвия блокировки?
M>а стоимость разруливания конфликта для версионного механизма намного выше чем для блокировочного, так как конфликт версий фактически означает откат транзакции.

брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"?

И вообще, по треду дальше идут непонятные намеки на откат при конфликте на уровне snapshot,
при том что снапшотов (таких) в MS SQL еще никто не ел. Давайте уж более близкое сравнивать —
в RC никаких "откатов" не надо.
И явное управление завершением транзакции при конфликтах — это благо, а не недостаток.
Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL —
это наследованная проблема, которую, думаю, уже не исправить. Отсюда и вольное
обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п.

В целом я так понял, что автор поста не любит версионность, и считает что Microsoft
совершенно зря (сдуру?) ввел ее поддержку в MS SQL 2005. Иже с ними все упомянутые
мной в другом посте сервера, поддерживающие версионность.

Здравствуйте, Аноним, Вы писали:

вот черт, я не "Аноним", я kdv, www.ibase.ru.

Merle,

M> ты правда считаешь, что это будет быстрее,
M> чем если сервер разрулит это автоматически?

Быстрее не будет, естественно. Весь вопрос — должен ли уровень изоляции RC диктовать отсутствие конфликтов или нет. Если да, то перевыполнение оператора сервером допустимо и, более того, желательно. А вот если нет, то по-хорошему надо спросить юзверя. Вдруг его логика вместо тупого повтора захочет пойти в обход?

M> Даже при Snapshot? В этом случае ты не сможешь гарантировать
M> отсутствие конфликтов и, собственно snapshot-ность, если
M> сможешь серверу явно указать перезапись чужой версии.

Перезапуск оператора после конфликта в снапшоте бесполезен. Авторестарт транзакции — некорректен. Остается выбор: роллбачить автоматом или клиент пусть сам это делает. Дело вкуса, IMHO. Хотя, если держать в памяти гипотетическую вероятность альтернативного пути со стороны клиента, то лучше обойтись без автомата.

Здравствуйте, <Аноним>, Вы писали:

А>брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"?
Потому что стоимость отката очень высока.

А> Давайте уж более близкое сравнивать — в RC никаких "откатов" не надо.
Формально не надо, на практике Oracle, как правило, откатывает, IB/FB спрашивает клиентский код, что по скорости еще хуже.

А>И явное управление завершением транзакции при конфликтах — это благо, а не недостаток.
Недостаток. Не хочу сейчас ввязываться в дискуссии относительно такого поведения вообще, однако в данном топике идет разговор именно об OLTP задачах, а в таких условиях это недостаток, хотя бы из соображений производительности.

А>Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL -это наследованная проблема, которую, думаю, уже не исправить.
Во-первых — это не проблема, во-вторых ее уже исправили (ключевые слова ADO.Net 2.0, MARS, Async Query), а в третих это-то уж здесь совершенно непричем.

А>Отсюда и вольное обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п.
Еще раз. Взвалить решение о коммите на клиентский код, который ничего не знает о внутреннем состоянии шедулера и о том чем занимаются конкурентные транзакции в этот момент, додумался только IB, ни одна другая СУБД подобными вещами не занимается.

А>В целом я так понял, что автор поста не любит версионность, и считает что Microsoft
А>совершенно зря (сдуру?) ввел ее поддержку в MS SQL 2005. Иже с ними все упомянутые
А>мной в другом посте сервера, поддерживающие версионность.
В целом жестоко ошибаешься. Ты упустил один очень важный момент — в данной подветке речь идет исключительно об OLTP системах. В целом же я очень приветствую шаг MS в эту сторону и моё скромное мнение заключается в том, что в РСУБД будущее не за версионниками или блокировочниками, а за гибридными системами, когда в зависимости от задачи можно выбирать наиболее удобный способ разруливания параллельных транзакций. Однако, если вернуться к теме данной подветки, то OLTP это как раз тот класс задач, когда выгоднее использовать блокировочный режим.

Здравствуйте, dimitr, Вы писали:

D>Быстрее не будет, естественно.
Об этом и речь. У нас на повестке дня OLTP системы, и здесь очень критично время одной транзакции.

D>Весь вопрос — должен ли уровень изоляции RC диктовать отсутствие конфликтов или нет.
Я описался, речь не о конфликтах а об аномалиях, конечно же. Ну да не важно...
Формально при RC можно забить и перезаписать, на практике Oracle запрос перевыполняет (хотя там более сложная механика, но это лирика), IB вообще пользователя спрашивает.
А на данный момент нас интересует именно вопрос производительности, и по производительности оба эти подхода сливают со свистом простому ожиданию на блокировке. Именно об этом и идет речь в данной подветке.

Здравствуйте, dimitr, Вы писали:

D> При неразрешенном конфликте всегда будет только откат оператора. Ты про это?
Возможно, дело давнее, но сути это не меняет...

D>Он перевыполняет только конкретную операцию записи (вместе с проверкой предиката) или весь запрос?
Запрос, не транзакцию целиком, а конкретный запрос в этой транзакции.

D> А в режиме NO WAIT (или какой там у него аналог) он как поступает?
Откат запрса и исключение, если он на блокировку нарвался. Если же блокировки нет, а данные успели поменять, то опять-таки, откат запроса и выполнение его по новой.
Но здесь я могу наврать, давно в руках не держал.

D> Кстати, насколько перезапись теоретически правильна для RC — я четкого ответа найти не смог.
Теориетически при RC перезаписать можно совершенно спокойно, формально никаких противоречий нет.

Здравствуйте, <Аноним>, Вы писали:

А>"вообще" иметь в виду версионный механизм странно,
Ничего странного, поскольку рассматривалась не конкретная реализация, а общие теоретические принципы.

А>пока будем считать, что это копия с Interbase, а уж удачная или нет — посмотрим.
Общего с IB там только версионность на уровне записи, а не страницы, как в Oracle или Postgree...

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"?
M>Потому что стоимость отката очень высока.

Гм. Есть методика измерения и\или конкретные цифры ?

А>> Давайте уж более близкое сравнивать — в RC никаких "откатов" не надо.
M>Формально не надо, на практике Oracle, как правило, откатывает, IB/FB спрашивает клиентский код, что по скорости еще хуже.

Оператор откатывается автоматически. А тр-ция тут причём ??? Ах да, стиль программирования, прививаемый MSSQL'ом, не рекомендует явного управления тр-циями и мало кто из T-SQL кодеров пользуется запрещённым оператором "BEGIN TRAN". Отсюда и знак равенства между откатом оператора и тр-ции

...

А>>Собственно, невозможность старта параллельных транзакций в одном коннекте в MS SQL -это наследованная проблема, которую, думаю, уже не исправить.
M>Во-первых — это не проблема, во-вторых ее уже исправили (ключевые слова ADO.Net 2.0, MARS, Async Query), а в третих это-то уж здесь совершенно непричем.

И шо 2 тр-ции будут жить в одном коннекте ?

А>>Отсюда и вольное обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п.
M>Еще раз. Взвалить решение о коммите на клиентский код, который ничего не знает о внутреннем состоянии шедулера и о том чем занимаются конкурентные транзакции в этот момент, додумался только IB, ни одна другая СУБД подобными вещами не занимается.

Давно я так не смеялся Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо
Ни одна СУБД не занимается такой порнографией, как невозможность перехватить и обработать ошибку (некоторые их виды). В Юконе может и натанет "щастье", но не скоро он заменит предыдущие версии... так что жрать кактусы ещё долго нужно будет... Это об откатах и их обработке в одном продвинутом блокировочнике

Хорсун Влад

Здравствуйте, Merle, Вы писали:

А>>брр... а мы то живем, и не знаем. Почему же интересно, стоимость "выше"?
M>Потому что стоимость отката очень высока.

опять мы про "откат", который требуется только для snapshot, и который
имеет мало смысла в том же самом OLTP.

А>>И явное управление завершением транзакции при конфликтах — это благо, а не недостаток.
M>Недостаток. Не хочу сейчас ввязываться в дискуссии относительно такого поведения вообще, однако в данном топике идет разговор именно об OLTP задачах, а в таких условиях это недостаток, хотя бы из соображений производительности.

чистых OLTP уже давно нет. Обязательно на десять OLTP-пользователей найдется пара-тройка отчетников или аналитиков.

А>>Отсюда и вольное обращение со всякими commit/rollback в триггерах, в "провайдерах" и т.п.
M>Еще раз. Взвалить решение о коммите на клиентский код, который ничего не знает о внутреннем состоянии шедулера и о том чем занимаются конкурентные транзакции в этот момент, додумался только IB, ни одна другая СУБД подобными вещами не занимается.

моя твоя не понимай, и так же с другой стороны. Мне непонятно, как вообще сервер может чего-то там решать
за меня.

M>Однако, если вернуться к теме данной подветки, то OLTP это как раз тот класс задач, когда выгоднее использовать блокировочный режим.

в чистом виде — да. Но — например, зачем Borland ввел понятие Cached Updates, когда на клиенте сначала оформляется
пакет изменений, а потом выстреливается? Короткая транзакция, да, но чем дольше момент от начала изменений на клиенте до старта транзакции на сервере, тем меньше шансов успешно обновить данные. Проблемы "кэширования" никто не отменял, и здесь ни версионник, ни блокировочник не имеют разницы в плане "устаревания" данных.

Merle,

M> А на данный момент нас интересует именно вопрос производительности,
M> и по производительности оба эти подхода сливают со свистом простому
M> ожиданию на блокировке. Именно об этом и идет речь в данной подветке.

В IB/FB стартуешь транзакцию READ_COMMITTED NO_REC_VERSION WAIT и он работает как блокировочник, т.е. при обнаружении нами активной чужой версии записи ждем завершения (любого) транзакции-конкурента на ее (записи) чтении, а не на апдейте. После чего успешно читаем результат и перезаписываем его своим. Для версионника это не совсем ожидаемый режим и он редко кем используется, однако он существует и при желании может быть применен в OLTP.

Merle,

M> Общего с IB там только версионность на уровне записи,
M> а не страницы, как в Oracle или Postgree...

Насколько я в курсе, страничная версионность есть только в Oracle. Как PGSQL, так и InnoDB в MySQL реализуют версионность записей. Ноги у которой растут от RDB/ELN и InterBase, и на сей день вырасли аж до MSSQL. И это "только" диктует очень много схожих технических решений для всех упомянутых СУБД.

Здравствуйте, dimitr, Вы писали:

D> Ноги у которой растут от RDB/ELN и InterBase, и на сей день вырасли аж до MSSQL. И это "только" диктует очень много схожих технических решений для всех упомянутых СУБД.
InnoDB, вообще отдельная пестня — дитя финского энтузиаста, да и строить общность только на том, что механизм работает на одинаковом уровне — занятие неблагодарное. В отличии от всех остальных версионников, сиквел еще и обеспечивает полноценный блокировочный механизм, так что вряд ли тут можно рассуждать о копировании идей.
Вообще же, корни растут из работ по MV over 2PL, того же Бернстайна, Грея, Беренсона, ect, которые в 70х-80х двигали теорию CC, а нонче работают на MS.

Здравствуйте, dimitr, Вы писали:

D> Для версионника это не совсем ожидаемый режим и он редко кем используется, однако он существует и при желании может быть применен в OLTP.
Отлично. Теперь читаем еще раз внимательно о чем речь. Не о том, что IB плох, а о том какой механизм выгоднее использовать в определенной ситуации.
Да, в данной ситуации выгоднее использовать блокировочный, если IB это умеет — молодец, но речь здесь не об этом.