Здравствуйте, WolfHound, Вы писали:
SM>> Если я добавлю, что tr1 стартанута в режиме RC, вы останетесь на своем мнении? WH>Да. WH>Более того я предвидел то что ты начнешь говорить про уровни изоляции.
Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()
WH>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний.
Вот так. ANSI стандарт уже нам не нужен?
WH>Все остальное это соглашения с конкретной реализацией базы данных о том что ты не должен делать для того чтобы транзакция осталась сериализованной.
Да? То есть нужно обязательно работать только в SR IL? А RC (кста, по моему в MSSQL это умолчательный IL) — от лукавого?
WH>Если ты сознательно нарушаешь соглашения, то ты сам себе злобный Буратино.
Какие именно? Если можно, опишите подробно, где и что я нарушил?
WH>И уж темболие не стоит говорить что это правильный путь.
Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
А то у вас тут знаете ли очень любят голословные утверждения.
Так вот, согласно местным традициям заявляю: "Я иду правильным путём!"
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, SmlMouse, Вы писали:
SM>В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку):
Написали уже — T2 пользуется данными T1, в тото моментпока T1 не зафиксирована.
SM>Этот агрумент говорит только о зрении смотрящего.
О! Запомни это. Отсюда я смело делаю вывод, что с вашим зрением что-то не то.
SM>Что изменилось с тех времён?
Ничего.
SM>И раз уж ты говоришь, что утверждение не логично, то принято приводить доказательство.
Не мужик. Это ты сказал, что это утверждение логично — вот и приводи доказательство, почему оно логично.
SM>Ну и заодно, вдруг не знаешь:
Да, и вот это тоже почитай..
SM>Это нужно понимать как "ситауция возможна в обоих случаях"
Именно.
:
Твоя просьба звучала именно так.
T>Мне кажется, что если человек требует привести примые ссылки сыоих от своих оппонентов
Ты ошибаешься.. )
T>Именно следует, и именно из твоих слов.
Ты не правильно трактуешь мои слова. Думаю сначала следует научиться читать.
T>Но в принципе, я могу заблуждаться — по приведённым ссылкам я думаю это будет ясно видно.
Впринципе это видно и без ссылок.
КДВ>что такое "миниоткаты" — это новый термин?
Это слэнговое название особенности реализации RC в Оракле. В принципе, механизм действия я описал.
КДВ>или это внутренний savepoint, который ЕСТЬ в IB/FB?
К сэйвпоинтам это не имеет никакого отношения.
КДВ>не буду. я хочу аргументации, со ссылкой.
Ссылкой на что? Аргументы, в виде механизма работы оракла при RC, я описал. FB, очевидно, так не поступает.
Есть контраргумнты, о знатоки версионности и FB?
КДВ>да ну?
Ну да.
КДВ> или версионность в MS SQL уже 23 года? Или Вы (ты) работаете(шь) с версионным сервером лет 12 ?
Причем тут MSSQL?
КДВ>В ЧЕМ ОНА ОТЛИЧАЕТСЯ. Прошу сообщить.
Я. уже. сообщил. Я даже не поленился алгоритм описать, правда без бодробностей. Может потрудишься прочитать?
КДВ>то есть, я умом не вышел?
Откуда я знаю, чем ты не вышел?
КДВ>Напрягитесь, пожалуйста, хоть один вменяемый аргумент дать.
Я вам вменяемых аргументов надавал — на полгода разбираться хватит.
КДВ>Я Вам уже кучу ссылок дал, а Вы все как-то по нулям.
Ссылки только что-то не конкретненькие, я тоже в MSDN послать могу, у меня не застрянет...
SM> Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()
Не пропустил, так как в коде есть строчка update table1 set field2=updated where field1 = 1, где 1 — незафиксированные данные первой транзакции.
A>Ты наверное не догнал,
не догнал. Уж очень задача экзотическая. A> но записи надо печатать по одной или более, на одном или более принтерах, причем сбойнуть может любой принтер в любой момент, а остальные должны продолжать печатать. Т.е. если я работаю в одной транзакции то должен после каждой делать коммит вместо того чтобы в данном случае просто сделать откат обновляющей транзакции? Я правильно понимаю?
Конечно. Я не понимаю, каким образом тебе поможет откат обновляющей транзакции.
S>>А чем вам поможет snapshot транзакция? Покажите мне, что делается в первой транзакции, и что во второй. A>1. select bla-bla-bla from table A>2. delete from table where id=:id
И почему это делается в разных транзакциях, а не в одной? A>С таблицей однозначно делаются только операции вставки и удаления. Причем некоторые записи должны быть напечатаны в одном пакете, и если произошла хоть одна ошибка при печати то откатить весь пакет и соответственно пропечатать отмену печати при необходимости.
То, что печатается пакетом, делается в одной транзакции. A>Первая читающая транзакция, можно сделать так что нагрузка сервера будем минимальна изначально (кстати, про такое Вы наверное не знаете?).
Может, и не знаю. Пока что я вообще не могу понять, чего хочется получить. A>Вторая чисто под удаления запускается. В чем порочен данный метод? Или мне надо делать два коннекта?
Удобнее всего делать столько коннектов, сколько принтеров. A>Если нет, то лучше нагружать сервер откатами транзакций и иже с ним?
Откаты транзакций существуют независимо от нашего сознания. Если есть необходимость откатить изменения — она произойдет, и стоимость ее слабо зависит от того, в каком количестве транзакций ну A>P.S. Можно конечно запускать запросы по одному, но по мне это достаточно геморный вариант. Хотя Вам виднее. Я был бы раз если мне предложат более простой способ для решения этой задачи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>а если мне надо читать одновременно и в TR2 и в TR1 ?
Что значит "одновременно"? Я еще раз объясняю: если у вас нет зависимостей по модификациям, то нет никакой разницы, одновременно вы это делаете или по очереди. Вам что, нужно определение сериализуемости процитировать? Простите, не верю.
КДВ>давайте не будем таким способом объяснять "ненужность" одновременно активных транзакций.
Хорошо, давайте объяснять нужность.
КДВ>А также фантазировать кто куда и какие данные переносит — это уже выходит за рамки КДВ>обсуждаемого, и скорее относится к здравомыслию пишущегопрограмму.
Я не фантазирую. КДВ>Например, Вам же никто не запрещает в ОДНОЙ программе открыть ДВА коннекта и обмениваться данными КДВ>между ЭТИМИ транзакциями? Нет? Ну и славно.
Нет, не запрещает. Но это не является необходимостью. Это — порочная практика, и пока что я не могу понять, почему вы так упорно защищаете ее аналог.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
): IB>Твоя просьба звучала именно так.
Хорошо, значит это ты не можешь аргументировать. Ок.
Можешь ли ты, привести ссылки на конкретные страницы/абзацы документации по любому серверу, где говорится о том, какое именно поведение клиента нарушает ACID гарантии сервера (здесь
)?
T>>Мне кажется, что если человек требует привести примые ссылки сыоих от своих оппонентов IB>Ты ошибаешься.. )
В том что ты не можешь привести не одной ссылки?
Или в том что ты некомпетентен в обсуждаемом вопросе?
T>>Именно следует, и именно из твоих слов. IB>Ты не правильно трактуешь мои слова. Думаю сначала следует научиться читать.
Значит, тебе следует научится выражатся яснее.
Хотя, похоже ты не очень понимаешь, что именно хочешь выразить. IB>Впринципе это видно и без ссылок.
В общем-то да.
Здравствуйте, SmlMouse, Вы писали:
SM>Здравствуйте, WolfHound, Вы писали:
SM>>> Если я добавлю, что tr1 стартанута в режиме RC, вы останетесь на своем мнении? WH>>Да. WH>>Более того я предвидел то что ты начнешь говорить про уровни изоляции. SM> Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit()
в что будет с твоей кислотностью, если после этого tr1 откатится? В твоем примере вызов commit tr1 не имеет смысла, т.к. в ней не сделано никаких изменений. Вот тебе модификация кода:
tr1->start; statement stm_tr1(tr1);
tr2->start; statement stm_tr2(tr2);
stm_tr1->Update; // Update table1 field1 set field1=1; // returned 1, test
stm_tr1->Fetch; // SELECT field1, field2 from table1; // returned 1, test
stm_tr2->update; // update table1 set field2=updated where field1 = 1
tr2->commit;
stm_tr1->Fetch; // SELECT field1, field2 from table1; // returned 1, updated
tr1->rollback;
WH>>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний. SM> Вот так. ANSI стандарт уже нам не нужен?
При чем здесь ANSI стандарт? Есть жесткая математика, которая описывает что такое сериализуемость транзакций.
Есть еще более жесткая реальность, в которой гарантированное обеспечение этой сериализуемости обходится очень дорого. К примеру, любой селект должен приводить к блокировке не только отфетченных данных, но и предиката, причем блокировка должна удерживаться до конца транзакции. Поэтому разработчики СУБД придумали такую штуку, как "уровни изоляции". Уровень изоляции вовсе не означает "ослабленной изоляции", как может показаться наивным детям. Уровень изоляции — это договоренность о том, чего нельзя делать во время такой транзакции, чтобы сериализуемость по прежнему обеспечивалась.
WH>>Если ты сознательно нарушаешь соглашения, то ты сам себе злобный Буратино. SM> Какие именно? Если можно, опишите подробно, где и что я нарушил?
Соглашения достаточно внятно описаны в уровнях изоляции. К примеру, в RC нельзя читать повторно те же данные. Иначе упорядоченность нарушится. SM> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду.
Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tonal-, Вы писали: IB>>Твоя просьба звучала именно так. T>Хорошо, значит это ты не можешь аргументировать. Ок.
T>Можешь ли ты, привести ссылки на конкретные страницы/абзацы документации по любому серверу, где говорится о том, какое именно поведение клиента нарушает ACID гарантии сервера (здесь
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, SmlMouse, Вы писали:
SM>> Это хорошо. Потому что твоё мнение верно только для DR или SR, либо ты в коде пропустил строчку tr2->Commit() IB>Не пропустил, так как в коде есть строчка update table1 set field2=updated where field1 = 1, где 1 — незафиксированные данные первой транзакции.
Ясно. В tr1 данные где-то меняются? Или всё-таки значение 1 существовало до момента старта tr1?
Если существовало, то где tr2 видит незафиксированные (читай некоммиченые) данные tr1 ?
P.S. У меня всё больше создаётся впечатление, что обсуждение закончилось, и начался низкопробный стёб.
Потому что если не стёб, то такого отрыва от реальности я давненько не видел...
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
пример поскипан, ибо будем разираться по порядку. Когда закончим с моим, вернёмся к твоему.
WH>>>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний. SM>> Вот так. ANSI стандарт уже нам не нужен? S>При чем здесь ANSI стандарт? Есть жесткая математика, которая описывает что такое сериализуемость транзакций. S>Есть еще более жесткая реальность, в которой гарантированное обеспечение этой сериализуемости обходится очень дорого. S>К примеру, любой селект должен приводить к блокировке не только отфетченных данных, но и предиката, причем блокировка должна удерживаться до конца транзакции.
Блокировка — это к MS SQL.
Мы сейчас обсуждаем поведение двух транзакций безприменительно к конкретному серверу.
S> Поэтому разработчики СУБД придумали такую штуку, как "уровни изоляции". Уровень изоляции вовсе не означает "ослабленной изоляции", как может показаться наивным детям. Уровень изоляции — это договоренность о том, чего нельзя делать во время такой транзакции, чтобы сериализуемость по прежнему обеспечивалась.
Вообще, придумали не разработчики конкретной СУБД, а целое сообщество людей. И отразили свои придумки в документе под названием
ANSI/ISO SQL Standard.
WH>>>Если ты сознательно нарушаешь соглашения, то ты сам себе злобный Буратино. SM>> Какие именно? Если можно, опишите подробно, где и что я нарушил? S>Соглашения достаточно внятно описаны в уровнях изоляции. К примеру, в RC нельзя читать повторно те же данные. Иначе упорядоченность нарушится.
Это где это такое написано? Можно мне почитать?
Я хочу: внятную ссылку с точностью до обзаца.
SM>> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду. S>Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными.
Почему? Почему я _ВСЕГДА_ ею должен пользоваться?
Можно увидеть что-то кроме голословных утверждений?
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
T>Хорошо, значит это ты не можешь аргументировать. Ок.
Аргументировать что? Твое неумение читать?
T>Можешь ли ты, привести ссылки на конкретные страницы/абзацы документации по любому серверу, где говорится о том, какое именно поведение клиента нарушает ACID гарантии сервера
Сколько раз тебе надо сказать, что я ни слова не говорил про гарантии сервера? С сервером все в порядке. Вы нарушаете требования изолированности транзакции на клиенте.
И тебе тот же вопрос, который вы все игнорируете — ты считаешь, что если требование изолированности нарушить на клиенте, то транзакция, в конечном итоге, станет более согласованной?
T>В том что ты не можешь привести не одной ссылки? T>Или в том что ты некомпетентен в обсуждаемом вопросе?
И в том и в другом.
T>Значит, тебе следует научится выражатся яснее.
Возможно. Но пытаться что-то объяснить, ктогда тебя не хотят слушать занятие вообще бесполезное.
IB>>Впринципе это видно и без ссылок. T>В общем-то да.
Рад, что ты это признаешь.. )
Здравствуйте, IB, Вы писали:
AC>>>>Иван, IB/FB никогда ничего "втихаря" не делает. IB>>>Кто-то говорил, что FB что-то делает в тихаря? AC>>И снова передёргиваем. Браво. IB>Мужик — ты о чем?
Вань, мужики в поле пашут.
Ко мне же, можешь обращаться просто — товарищ.
Напоминаю, речь идёт о твоих инсинуациях на тему:
=========Beginning of the citation============== IB>Оракл, в отличии от FB, при обнаружении того, IB>что данные менялись с момента начала запроса, IB>выполняет миниоткат и перезапуск запроса
=========The end of the citation================
AC>>Не-а, не чувствую. IB>Ну тогда и говориь не о чем.
И с юмором у тебя тоже напряг...
AC>>У Oracle строже по сравнению с чем? IB>По сравнению с реализацией в FB.
А как там у FB? А, Иван?
Расскажи нам. Как там не так?
А то всё фантазии какие-то, полунамёки...
=========Beginning of the citation============== IB>Таким образом RC запросы в Оракле более согласованные.
=========The end of the citation================
AC>>А зайти на сайт не пробовал? IB>Так где конкретная ссылка?
Вот она.
AC>>Попрошу не возводить на меня напраслину! IB>По делу тобой не было сказано ничего. IB>При попытке коснуться технических вопросов — несешь полную чушь.
Прекрасный перевод стрелок. Восхищен. Браво.
Всё ещё жду развернутого ответа, что ж там не так с RC у FB.
Изо всех сил...
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, SmlMouse, Вы писали:
SM>>В чем порок такого кода (поток один, приведён пвсевдо код, дабы не не захламлять ветку): IB>Написали уже — T2 пользуется данными T1, в тото моментпока T1 не зафиксирована.
Да? Честно-честно? А если всё-таки немного подумать?
Данные существовали до старта T1
Итак, некомпетентность твою я уже увидел.
SM>>И раз уж ты говоришь, что утверждение не логично, то принято приводить доказательство. IB>Не мужик. Это ты сказал, что это утверждение логично — вот и приводи доказательство, почему оно логично.
Уходим от твета?
Ну-ну. Возьми книжку и стань в угол.
SM>>Ну и заодно, вдруг не знаешь: IB>Да, и вот это тоже почитай..
После тебя
SM>>Это нужно понимать как "ситауция возможна в обоих случаях" IB>Именно.
Итак. Некомпетентность, перевод темы, уход от ответов.
Слив защитан
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, SmlMouse, Вы писали:
SM>Здравствуйте, Sinclair, Вы писали:
SM>пример поскипан, ибо будем разираться по порядку. Когда закончим с моим, вернёмся к твоему.
WH>>>>Так вот что я тебе скажу: Уровень изоляции есть только первый (сериализованный) и он же последний. SM>>> Вот так. ANSI стандарт уже нам не нужен? S>>При чем здесь ANSI стандарт? Есть жесткая математика, которая описывает что такое сериализуемость транзакций. S>>Есть еще более жесткая реальность, в которой гарантированное обеспечение этой сериализуемости обходится очень дорого. S>>К примеру, любой селект должен приводить к блокировке не только отфетченных данных, но и предиката, причем блокировка должна удерживаться до конца транзакции. SM> Блокировка — это к MS SQL. SM> Мы сейчас обсуждаем поведение двух транзакций безприменительно к конкретному серверу.
Дело не в блокировке. Обеспечение полной сериализуемости в условиях ad-hoc запросов стоит дорого независимо от используемой архитектуры. Иначе бы никаких уровней изоляции не существовало бы. SM> Вообще, придумали не разработчики конкретной СУБД, а целое сообщество людей. И отразили свои придумки в документе под названием SM> ANSI/ISO SQL Standard.
Совершенно верно. Этот стандарт разработан производителями СУБД.
S>>Соглашения достаточно внятно описаны в уровнях изоляции. К примеру, в RC нельзя читать повторно те же данные. Иначе упорядоченность нарушится. SM> Это где это такое написано? Можно мне почитать? SM> Я хочу: внятную ссылку с точностью до обзаца.
Тут уже давали тонны ссылок. Фактически, сам стандарт при описании уровней изоляции указывает действия, приводящие к нарушениям сериализуемости. Трактовать это нужно так: если вы хотите получать сериализуемость, избегайте сценариев, описанных в соответствующем уровне изоляции. Вот статья, уточняющая ANSI 92 в этом смысле.
SM>>> Нет уж. Пока меня мордой не тыкнут в перекрёсток, на котором я свернул на неправильный путь, я такие аргументы воспринимать не буду. S>>Ты отринул сериализуемость. А это есмь самое тяжкое преступление в проектировании систем управления данными. SM> Почему? Почему я _ВСЕГДА_ ею должен пользоваться?
Ну почему же всегда? Ты должен ей пользоваться только в тех жалких 99% случаев, когда нарушение целостности данных может привести к убыткам. SM> Можно увидеть что-то кроме голословных утверждений?
Цитируем http://emanual.ru/download/www.eManual.ru_538.html#part_4:
Феномен P1 может быть представлен как запрещение на следующую последовательность операций:
(2.1) w1[x]...r2[x]... (a1 и c2 в любом порядке)
(выделение моё).
Ты что же, думал что уровни изоляции придумали для того, чтобы получать неконсистентные результаты? Нет, их придумали для того, чтобы повысить уровень параллелизма.
В идеале, СУБД должна принимать на выполнение сразу весь код транзакции, и автоматически выбирать уровень изоляции (а точнее, стратегию выполнения), обеспечивающую изоляцию для данного конкретного кода. Пока что (как и 15 лет назад) это утопия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alex.Che, Вы писали:
AC>Кем?
Чувством самосохранения и здравым смыслом. AC>В указанных статьях ни слова о запретах.
Гм. Есть такая штука, как логика.
Например, есть феномен Ожог, возникающий при следующей последовательности действий:
1. Нагрев конфорки К1 до температуры 180С
2. Прикосновение ладони Л1 к конфорке К1
Казалось бы, какое отношение имеет описание данного феномена к каким-то запретам? Однако, даже невооруженным мозгом можно понять, что из неизбежности ожога в таком сценарии следует правило:
П1. "Если вы не хотите получить Ожог, избегайте вышеописанного сценария"
Таким образом, при уровне изоляции "голые руки" нужно либо сначала трогать, потом греть, либо не трогать вовсе. На вопросы типа "кто мне запретит получить ожог, если я этого хочу" пусть ответит кто-нибудь другой.
В большинстве случаев мы ожидаем, что получение Ожога противоречит целям разработчика. Ну, ясен пень, что это не законы, а рекомендации.
Точно так же, как правило, от БД требуется сериализуемость транзакций (именно о ней говорит буковка I в слове "кислота"). Если лично вам она не требуется — тогда конечно, понижайте уровень, делайте фантомы. Только не забудьте уточнить у заказчика, согласен ли он на появление, к примеру, "исчезающих" записей в списке разговоров, или к тому, что остаток на складе не будет равен сумме всех движений. Нет проблем.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
IB>>Я не вижу чем это хорошо.
SM>>Этот агрумент говорит только о зрении смотрящего.
IB>О! Запомни это. Отсюда я смело делаю вывод, IB>что с вашим зрением что-то не то.
Здравствуйте, Sinclair, Вы писали:
AC>>Кем? S>Чувством самосохранения и здравым смыслом. AC>>В указанных статьях ни слова о запретах. S>Гм. Есть такая штука, как логика.
Мы уже победили, просто это еще не так заметно...
классика!