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

А> Гм. Есть методика измерения и\или конкретные цифры ?
Есть конкретные теоретические работы (ключевые слова: Мохан, Франклин, Ульман), и есть суровая практика. Откат очень дорогая операция практически во всех современных СУБД, если не брать в рассчет какую-нибудь экзотику (зато у этих ребят высокая стоимость фиксации). Тут выбирай, но осторожно, но выбирай. Либо дорогой роллбэк, либо дорогой коммит, дураков, понятное дело, нет.

А> Оператор откатывается автоматически.
Автоматически — это как?

А> А тр-ция тут причём ???
Какая транзакция?

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

А> Отсюда и знак равенства между откатом оператора и тр-ции
А>...
??? Какой знак равенства?

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

А> Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо
Правда? То есть ваш клиентский код всегда знает о других транзакциях, которые в этот момент выполняются в БД? Поздравляю, вам удалось достичь совершенства.
Только вот еще раз повторюсь, до такой конструкции додумался только один IB, а ни одна из серьезных БД шаловливые ручки разработчика до такой тонкой механики не допускает, даже панки из Oracle.
Ни на какие размышления не наводит?

Здравствуйте, Кузьменко Д.В., Вы писали:

КДВ>опять мы про "откат", который требуется только для snapshot, и который
КДВ>имеет мало смысла в том же самом OLTP.
Почему мало? Уровень изоляции здесь непричем, в OLTP задачи вполне входят требования высокого уровня согласованности. К слову, tpc-c тесты обязаны выполняться на уровне не ниже RR.

КДВ>чистых OLTP уже давно нет. Обязательно на десять OLTP-пользователей найдется пара-тройка отчетников или аналитиков.
Пара тройка аналитиков — это все еще OLTP. И не надо опять разговор в сторону уводить, есть задача — OLTP, какое решение будет наиболее удачным, блокировочное или версионное? Ответ — блокировочное, почему — я объяснил, есть возражения?

КДВ>моя твоя не понимай, и так же с другой стороны. Мне непонятно, как вообще сервер может чего-то там решать за меня.
Вот в этом-то и проблема версионного механизма. В блокировочнике откат — это внештатная ситуация, нарушение констрейнта и прочий караул. А в версионнике — вполне обыденный случай, который, тем не менее, требует (по твоим же словам) вмешательства клиентского кода. В блокировочниках просто нет этой проблемы, ваще.

КДВ>в чистом виде — да.
Ну вот и договорились. В данном топике речь шла именно +/- о чистом OLTP, и ни о чем более. Опять-таки намеренно не хочу ввязываться в разговор о практичности такого подхода.

КДВ> Но — например, зачем Borland ввел понятие Cached Updates, когда на клиенте сначала оформляется пакет изменений, а потом выстреливается?
Судя по описанию, там появились трезвые умы, но боюсь поздно..

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

Merle,

M> Теперь читаем еще раз внимательно о чем речь.

В этой ветке мысль зело широко разлилась

M> в данной ситуации выгоднее использовать блокировочный

Если под блокировочным ты понимаешь "писатель блокирует читателя", тогда согласен, т.к. это даст возможность ждать и перезаписывать без "дорогих" откатов, повышая производительность OLTP. Вот только отсутствие откатов достигается безотносительно архитектуры сервера, как я уже показал. Т.е. фраза "в версионнике более дорогие откаты" некорректна. В RC WAIT версионник может работать без откатов. В RC NO WAIT или RR/SNAPSHOT откат обязателен (оператора или транзакции соответственно) в любой архитектуре и я не вижу, как внутри себя сервер этого может избежать.

Есть возражения?

Merle,

M> InnoDB, вообще отдельная пестня — дитя финского энтузиаста

У одного финского энтузиаста неплохо получилось, знаешь-ли

M> строить общность только на том, что механизм работает на
M> одинаковом уровне — занятие неблагодарное

Общность — понятие растяжимое и не равное идентичности. Я никогда не говорил, что у всех все слизано с реализаций начала 80-х. Но общих идей и алгоритмов достаточно много, велосипеда никто заново не изобрел.

К сожалению, по версионности в MSSQL низкоуровневой информации не так и много. Например, я до сих пор не могу выяснить, индексы у них версионные или нет (т.е. содержит ли ключ метку транзакции). Что насчет версий блобов? Критерии старта фоновой сборки мусора?

M> В отличии от всех остальных версионников, сиквел еще и
M> обеспечивает полноценный блокировочный механизм

Наверное, мне никогда не понадобится блокировочный RR вместо версионного SNAPSHOT. А для RC у меня есть оба варианта. Причем все это задается на уровне транзакции и действует для любой таблицы. В свете этого полезность полноценного блокировочного механизма мне сомнительна. Впрочем, всегда лучше когда что-то есть, чем когда его нет Лишь бы есть не просил без надобности. Осталось убедиться, что версионность в MSSQL настолько же полноценна, как и блокировочность.

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

D>У одного финского энтузиаста неплохо получилось, знаешь-ли
Да как сказать, не плохо, конечно, ни о не так чтоб уж очень хорошо...

D>Но общих идей и алгоритмов достаточно много, велосипеда никто заново не изобрел.
Естественно, с этим никто и не спорит.

D> Например, я до сих пор не могу выяснить, индексы у них версионные или нет (т.е. содержит ли ключ метку транзакции).
AFAIK нет, не содержит.

D> Что насчет версий блобов?
Если я правильно помню, то там версии на каждую страницу блоба.

D> Критерии старта фоновой сборки мусора?
Такие же как и у checkpoint-а.

D>Наверное, мне никогда не понадобится блокировочный RR вместо версионного SNAPSHOT.
Не зарекайся. При записи версионный снапшот — это гарантированый откат в случае конфликта версий, поэтому RR может оказаться очень кстати.

D> А для RC у меня есть оба варианта.
Ага, и Row Level Read Lock есть? И Update Lock есть? В IB уже не приходится фиктивный update делать для гарантии отсутствия изменений в записи на время транзакции делать?

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

D>В этой ветке мысль зело широко разлилась
Не моими усилиями.. Набежали почему-то оскорбленные в лучших чувствах IB-шники и начали спорить с тем, что я никогда не писал..

D>Если под блокировочным ты понимаешь "писатель блокирует читателя", тогда согласен, т.к. это даст возможность ждать и перезаписывать без "дорогих" откатов, повышая производительность OLTP.
Именно.

D>Вот только отсутствие откатов достигается безотносительно архитектуры сервера, как я уже показал.
Ну причем здесь архитектура конкретного сервера? Я про конкретный сервер не говорил ни слова. Более того, изначально речь шла о некоем сервере, который имеет в себе оба этих механизма, и я лишь утверждал, что из этих двух (2PL и MV over 2PL) в OLTP задаче выгоднее использовать просто 2PL. Все.

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

D> В RC WAIT версионник может работать без откатов.
Теоретически да, на практике, либо таки откатывают, либо спрашивают пользователя — что хуже (для OLTP) — неизвестно.

D>В RC NO WAIT или RR/SNAPSHOT откат обязателен (оператора или транзакции соответственно) в любой архитектуре и я не вижу, как внутри себя сервер этого может избежать.
Во-первых, для Snapshot, если речь идет о версионнике, то откат должен быть обязательно всей транзакции, одним оператором здесь не отделаешься.
А во-вторых, если речь идет о блокировочнике, то там и RR и даже serializable без откатов достигаются очень просто — за счет блокировок время начала опоздавшей транзакции сдвигается вперед, относительно успевшей, поэтому опоздавшая ничем навредить не может и откатывать ее не надо.

Merle,

M> AFAIK нет, не содержит.

И, соответственно, select count(*) через full index scan невыполним?

M> Если я правильно помню, то там версии на
M> каждую страницу блоба.

Если изменены только не-блоб поля записи с блобом, версия блоба будет создана или нет? В IB/FB — нет.

M> Такие же как и у checkpoint-а.

Направь в онлайн-доку, плиз. Для повышения моей эрудиции

M> Не зарекайся. При записи версионный снапшот — это
M> гарантированый откат в случае конфликта версий, поэтому
M> RR может оказаться очень кстати.

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

M> Ага, и Row Level Read Lock есть?
M> И Update Lock есть?

SELECT blah-blah WITH LOCK дает мне нормальный update lock в FB. С помощью чисто версионного механизма. Локов на чтение (на уровне записи) действительно нет.

Merle,

M> речь шла о некоем сервере, который имеет в себе оба этих
M> механизма, и я лишь утверждал, что из этих двух (2PL и MV
M> over 2PL) в OLTP задаче выгоднее использовать просто 2PL.

Поясни "MV over 2PL", плиз. IMHO, где-то тут гуляет легкое непонимание друг друга. Либо мы говорим об одном и том же разными словами Я выше имел ввиду, что блокирование записи на чтение в RC-транзакции достигается родными методами как в 2PC, так и в MV. В чем тут выгода 2PL?

D>> В RC WAIT версионник может работать без откатов.
M> Теоретически да, на практике, либо таки откатывают, либо
M> спрашивают пользователя — что хуже (для OLTP) — неизвестно.

Я показывал пример с no_rec_version, где откатов нет. Чем эта практика не устраивает? Или ты хочешь видеть неблокируемость по чтению и при этом отсутствие откатов?

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

D>Поясни "MV over 2PL", плиз. IMHO, где-то тут гуляет легкое непонимание друг друга.
Начну издалека.. Есть куча способов обеспечить согласованность параллельных транзакций, (aka типы планировщикаов транзакций (sheduling type)). Среди них встречаются, блокировочник — основанный на протоколе 2 фазной блокировки (2PL), Timestamp Ordering, основанный на временных метках, Serialization Graph Testing... И ни один из них не является мультиверсионным. Мультиверсионность реализуется поверх одного из этих типов планировщиков.
А рассматриваю я версионность именно поверх 2PL, потому как, во-первых, на сколько мне известно, все современные СУБД, включая IB, реализуют мультиверсионность в первую очередь поверх 2PL, хотя, естественно, не без своих хитрых наворотов. А во-вторых, в остальных типах планировщиков, и без мультиверсионности все очень грустно с откатами...

D> Я выше имел ввиду, что блокирование записи на чтение в RC-транзакции достигается родными методами как в 2PC, так и в MV. В чем тут выгода 2PL?
В том, что для MV "родным" методом блокирования являтся фиктивное обновление и порождение новой версии, со всеми вытекающими.

D>Я показывал пример с no_rec_version, где откатов нет. Чем эта практика не устраивает?
Тем что клиентский код спрашивают делать откат или все-таки не надо... Или я что-то не так понял?

D>Или ты хочешь видеть неблокируемость по чтению и при этом отсутствие откатов?
Это был бы идеальный вариант..

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

D>И, соответственно, select count(*) через full index scan невыполним?
Почему? вполне...
Но я выясню подробнее, как именно работает версионность с индексами.

D>Если изменены только не-блоб поля записи с блобом, версия блоба будет создана или нет? В IB/FB — нет.
Если я правильно помню, то там нет такого понятия как версия блоба, есть версия страницы блоба. Соответственно версии страниц блоба не поменяются, блобы лежат в отдельном месте, и обрабатываются независимо.

D>Направь в онлайн-доку, плиз. Для повышения моей эрудиции
Нуу... где-то здесь:
http://msdn2.microsoft.com/en-us/library/ms188748.aspx
(Events That Cause Checkpoints)

и здесь: http://msdn2.microsoft.com/en-us/library/ms189573(en-US,SQL.90).aspx
(Activities That Cause a Checkpoint)

D>Если я пользую снапшот, значит я готов к откату и ручной обработке конфликтов.
Ну готов-то понятно, просто это может оказаться невыгодно или неудобно, в зависимости от задачи.

D>С помощью чисто версионного механизма.
Чисто-версионный механизм — это значит фиктивный update?

Merle,

M> Почему? вполне...

Нет метки транзакции -> неясно, видна ли нам запись.

M> Но я выясню подробнее, как именно работает версионность с индексами.

ОК, весьма благодарен.

M> Чисто-версионный механизм — это значит фиктивный update?

По сути — да. Новая версия записи, помеченная моей транзакцией.

Merle,

M> В том, что для MV "родным" методом блокирования являтся
M> фиктивное обновление и порождение новой версии, со всеми
M> вытекающими.

В твоем примере OLTP нет фиктивного обновления. Все они там абсолютно настоящие. А раз от них никуда не деться, то почему бы и не подождать подтверждения активной версии? Факт ее наличия играет роль лока уровня записи в 2PL.

Я согласен со "всеми вытекающими" про искуственные read lock / update lock — в версионнике это всегда накладные расходы. Но в обсуждаемом OLTP нет ничего лишнего.

M> Или я что-то не так понял?

Угу. Перечитай еще раз. В режиме no_rec_version мы ждем завершения конкурента на чтении и потом перезаписываем. Соответственно, нет конфликта, нет отката и незачем спрашивать клиента. Т.е. версионный RC может легко эмулировать поведение блокировочника. Если хотим неблокирующее чтение — работаем в режиме rec_version (всегда читаем видимые нам версии и ждем конкурента только на записи) и ловим откаты. Свой выбор делаем на уровне транзакции.

M> Это был бы идеальный вариант..

Еще бы

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

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

А>> Гм. Есть методика измерения и\или конкретные цифры ?
M>Есть конкретные теоретические работы (ключевые слова: Мохан, Франклин, Ульман), и есть суровая практика. Откат очень дорогая операция практически во всех современных СУБД, если не брать в рассчет какую-нибудь экзотику (зато у этих ребят высокая стоимость фиксации). Тут выбирай, но осторожно, но выбирай. Либо дорогой роллбэк, либо дорогой коммит, дураков, понятное дело, нет.

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

А>> Оператор откатывается автоматически.
M>Автоматически — это как?

Движком. Без участия кого-либо еще. Я не знаю как можно не понять вышесказанное

А>> А тр-ция тут причём ???
M>Какая транзакция?

В любом SQL сервере любое действие выполняется в рамках тр-ции. Даже в MSSQL. Не знал ?

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

Повторить написанное ? Перечитай сам

А>> Отсюда и знак равенства между откатом оператора и тр-ции
А>>...
M>??? Какой знак равенства?

Две горизонтальные параллельные палочки.

Ок, вот пример для детсада:

BEGIN TRAN
INSERT INTO T1...
INSERT INTO T2... -- здесь ошибка, любая — PK violation, триггер и т.п.
COMMIT

Q Останется ли запись в T1 ?
A Конечно.

Q Что было откачено — второй INSERT или вся тр-ция ?
A Конечно только оператор

Q Зависит ли это поведение от FB\MSSQL ?
A Нет конечно, везде одинаково

Q Кем делается COMMIT\ROLLBACK ?
A Клиентом, конечно, а как же ещё ?

Q Как клиентом, а если это скрипт\процедура ?
A И шо ? Это не клиент писал этот код ?


А>> И шо 2 тр-ции будут жить в одном коннекте ?
M>Таки да.

Таки поздравляю

А>> Только клиентский код знает о том, как ему нужно обрабатывать ошибку — откатом, повтором, другим оператором или ещё как. К счастью о "внутреннем состоянии шедулера" для этого знать не надо
M>Правда? То есть ваш клиентский код всегда знает о других транзакциях, которые в этот момент выполняются в БД? Поздравляю, вам удалось достичь совершенства.

А зачем ему это знать ???

M>Только вот еще раз повторюсь, до такой конструкции додумался только один IB, а ни одна из серьезных БД шаловливые ручки разработчика до такой тонкой механики не допускает, даже панки из Oracle.
M>Ни на какие размышления не наводит?

Наводит. Ты абсолютно не понимаешь предмет беседы

--
Хорсун Влад

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

D>Нет метки транзакции -> неясно, видна ли нам запись.
Записи которые не видны не присутствуют в индексе, иначе им вообще бы толком пользоваться нельзя было, но это действительно надо уточнить.

D>По сути — да. Новая версия записи, помеченная моей транзакцией.
Опяь-таки, это несколько более дорогая операция по сравнению с установкой блокировки. Не даром в том же Oracle введен для таких случаев хинт FOR UPDATE, который ставит честную блокировку, а не занимается порождением фиктивных обновлений.

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

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

D>Угу. Перечитай еще раз. В режиме no_rec_version мы ждем завершения конкурента на чтении и потом перезаписываем.
<...>
D> Свой выбор делаем на уровне транзакции.
Ok, разумно, а на уровне запроса нельзя?

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

А>Т.е. подтвердить свои предположения мы не можем, как впрочем и ожидалось
Открой любой учебник — это не сложно.

А>Движком. Без участия кого-либо еще. Я не знаю как можно не понять вышесказанное
Непонять можно очень просто, мне совершенно непонятно какое отношение имеет все тобой написанное, к обсуждаемой теме. Ну совершенно.
Если не затруднит, будь пожалуйста более конкретен в своих претензиях.
Явно ощущается, что ты чем-то возмущен и недоволен, только абсолютно непонятно чем. Если есть какие-то конкретные возражения, по конкретным пунктам, то по ним и излагай, и, очень прошу, без терминов типа "детсад" и "для маленьких", а с конкретными примерами и строго по сути. А то ты приписываешь мне некие тезисы, причем даже непонятно какие именно, и пытаешься с ними спорить, очень сложно в таких условиях добиться какого-либо конструктива.

А>Повторить написанное ? Перечитай сам
Хорошо, переформулирую. К чему? Зачем излагать столь очевидные заблуждения, да еще и не имеющие никакого отношения к обсуждаемому вопросу, с таким безапеляционным пафосом?

А>Ок, вот пример для детсада:
А>BEGIN TRAN
А>INSERT INTO T1...
А>INSERT INTO T2... -- здесь ошибка, любая — PK violation, триггер и т.п.
А>COMMIT

А>Q Останется ли запись в T1 ?
А>A Конечно.
Для MSSQL-я ответ не верный, так как в данном случае поведение сервера зависит от параметров соединения.

А>Q Что было откачено — второй INSERT или вся тр-ция ?
А>A Конечно только оператор
Ошибаешься, см ответ выше.

А>Q Зависит ли это поведение от FB\MSSQL ?
А>A Нет конечно, везде одинаково
Ну ты сам понял.

А>Q Кем делается COMMIT\ROLLBACK ?
А>A Клиентом, конечно, а как же ещё ?
Опять-таки, для MSSQL-я ответ не верный, в большинстве практических случаев все вопросы решаются на сервере.

А>Q Как клиентом, а если это скрипт\процедура ?
А>A И шо ? Это не клиент писал этот код ?
Очевидно, что в данном случае имеется ввиду, в рамках какого процесса выполняется принятие решения об откате или продолжении работы транзакции, а не о том кто писал этот код.

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

А>Наводит. Ты абсолютно не понимаешь предмет беседы
Конечно. Я абсолютно не понимаю что ты пытаешься доказать, объяснить или описать, потому как все излагаемое тобой не имеет никакого отношения к предмету разговора в этой ветке.

Merle,

M> Записи которые не видны не присутствуют в индексе,

Гммм. Они там по коммиту появляются, что-ли? Бред ведь, сам посуди.

M> иначе им вообще бы толком пользоваться нельзя было,

Все остальные версионники пользуются, тем не менее.

M> но это действительно надо уточнить.

Потому и спрашиваю. У каждого подхода (хранить метки в ключе или нет) есть свои достоинства и недостатки. Интересно, какой путь избрали в MS.

M> Опять-таки, это несколько более дорогая операция по сравнению
M> с установкой блокировки.

Не спорю. Но возможность есть.

Merle,

M> Ok, разумно, а на уровне запроса нельзя?

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

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

А>> И шо 2 тр-ции будут жить в одном коннекте ?
M>Таки да.

Дорогой Merle. Я почему-то думал, что ты разбираешься хотя бы в MSSQL. Я ошибался, извини.
Уверяю тебя, что MARS (Multiple Active Result Sets) не имеет никакого отношения к нескольким одновременно живущим тр-циям в рамках одного коннекта. Прочти это и подумай ещё раз :

msdn>Though SQL Server 2005 does not support multiple active transactions per connection, the programming model already accommodates such a future enhancement

Ещё раз прошу — отделяй тр-ции от операторов (резалтсетов etc), а то каша в твоей голове так там и останется

--
Хорсун Влад

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

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

А>>Т.е. подтвердить свои предположения мы не можем, как впрочем и ожидалось
M>Открой любой учебник — это не сложно.
Очень сильный аргумент. Особенно если учесть, что о работах по MVCC ты узнал пару дней назад — из этого топика и благодаря Алексу. Уже всё прочитал ?

А>>Движком. Без участия кого-либо еще. Я не знаю как можно не понять вышесказанное
M>Непонять можно очень просто, мне совершенно непонятно какое отношение имеет все тобой написанное, к обсуждаемой теме. Ну совершенно.
M>Если не затруднит, будь пожалуйста более конкретен в своих претензиях.

Я не люблю, когда люди говорят неправду о том, чего не понимают

M>Явно ощущается, что ты чем-то возмущен и недоволен, только абсолютно непонятно чем. Если есть какие-то конкретные возражения, по конкретным пунктам, то по ним и излагай, и, очень прошу, без терминов типа "детсад" и "для маленьких", а с конкретными примерами и строго по сути. А то ты приписываешь мне некие тезисы, причем даже непонятно какие именно, и пытаешься с ними спорить, очень сложно в таких условиях добиться какого-либо конструктива.

Ты утверждаешь, что IB\FB откатывает нечто в случае конфликта обновления. Ты не уточняешь что такое это нечто, но из твоих рассуждений очевидно, что ты не делаешь никакой разницы между откатом оператора и откатом тр-ции.

А>>Повторить написанное ? Перечитай сам
M>Хорошо, переформулирую. К чему? Зачем излагать столь очевидные заблуждения, да еще и не имеющие никакого отношения к обсуждаемому вопросу, с таким безапеляционным пафосом?

В чём же я заблуждаюсь ? То, что очевидно тебе, может быть совсем не очевидно другим и даже не быть правдой

А>>Ок, вот пример для детсада:
А>>BEGIN TRAN
А>>INSERT INTO T1...
А>>INSERT INTO T2... -- здесь ошибка, любая — PK violation, триггер и т.п.
А>>COMMIT

А>>Q Останется ли запись в T1 ?
А>>A Конечно.
M>Для MSSQL-я ответ не верный, так как в данном случае поведение сервера зависит от параметров соединения.

SET XACT_ABORT это тоже параметр, задаваемый клиентом. Т.к. только клиент может знать, как поступать, в случае проблем одного из операторов тр-ции. Если бы сервер не имел этого параметра, он или вёл бы себя как будто бы такой пар-р был OFF, или такой сервер давно выкинули бы на свалку. Для того, чтобы этот пример имел смысл, конечно же нужно иметь SET XACT_ABORT OFF, моё упущение, согласен.
Добрый MSSQL ставит SET XACT_ABORT ON по умолчанию, дабы не непрягать мозги T-SQL кодеров такими ненужными им вещами, как управление тр-циями. Аминь

А>>Q Что было откачено — второй INSERT или вся тр-ция ?
А>>A Конечно только оператор
M>Ошибаешься, см ответ выше.

А>>Q Зависит ли это поведение от FB\MSSQL ?
А>>A Нет конечно, везде одинаково
M>Ну ты сам понял.

Ага, MSSQL и тут отличился

А>>Q Кем делается COMMIT\ROLLBACK ?
А>>A Клиентом, конечно, а как же ещё ?
M>Опять-таки, для MSSQL-я ответ не верный, в большинстве практических случаев все вопросы решаются на сервере.

А что такое сервер ? Подумай хорошенько, перед тем как ошибаться опять. Hint — внутри 'сервера' есть много разного, в том числе и клиенты

А>>Q Как клиентом, а если это скрипт\процедура ?
А>>A И шо ? Это не клиент писал этот код ?
M>Очевидно, что в данном случае имеется ввиду, в рамках какого процесса выполняется принятие решения об откате или продолжении работы транзакции, а не о том кто писал этот код.

А причём тут процесс ? Интерпретатор скриптов T-SQL такой же клиент, по отношению к SQL-движку, как и программа Васи Пупкина. То, что он физически выполняется в одном процессе с SQL-движком, не даёт ему никаких дополнительных прав. И любая последовательность операторов должна выполняться одинаково, независимо от того батч это, процедура, или их исполняют по-одному. Еще раз — перестань ставить знак равно между откатом оператора и тр-ции. Даже если это иногда выглядит, как одно и то же

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

А откуда ты знаешь какое состояние есть согласованное ??? БД знает только о декларативных ограничениях и их всегда выполняет. Но о логической согласованности (о том же балансе) она понятия не имеет. И причём тут состояние мифического внутреннего шедулера ?

А>>Наводит. Ты абсолютно не понимаешь предмет беседы
M>Конечно. Я абсолютно не понимаю что ты пытаешься доказать, объяснить или описать, потому как все излагаемое тобой не имеет никакого отношения к предмету разговора в этой ветке.

Тогда закончим на этом. Только не нужно высказываться о IB\FB — ты совершенно не владеешь вопросом.

--
Хорсун Влад