транзакции

← →
Johnmen © (2009-02-26 17:51) [40]

> MsGuns © (26.02.09 17:43) [37]
> Точна ?

Точняк.

> таки ВСЁ ?

таки да.

> И все правильные и неправильные одновременно.

Это ты как определил? Руководствуясь пролетарским самосознанием, похоже...:)

> Вместо четкого и ясного ответа сделать вумное лицо и ченить
> эдакое многозначительное загнуть все горазды :)

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

← →
MsGuns © (2009-02-26 19:38) [41]

>Johnmen © (26.02.09 17:51) [40]

Ответ в твоем стиле.
И, главное, убедительно так :)

← →
KSergey © (2009-02-27 05:49) [42]

> Johnmen © (26.02.09 17:46) [38]
> Твой этот пост можно расценить, как дуркование.

Ага, есть моё мнение и не правильное.
Свободен, говорить более не о чем.

← →
Sergey13 © (2009-02-27 10:12) [43]

> [36] MsGuns © (26.02.09 17:38)
> Блин, Серый, вот уж не думал что тебе надо объяснять прописные истины
Блин, Серый, мне кажется, что ты истины эти "прописные" придумал тоже тут. 8-)

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

Нет у сервера никакой алгоритмики. ИИ пока вроде не изобрели. Сервер просто выполняет команды, посылаемые клиентом. Часть кода может быть расположена и выполняться на сервере часть на клиенте. Но все равно это части прикладного ПО.

Единственный алгоритм сервера - ВСЕ изменения проводятся в рамках транзакций. Транзакциями можно управлять явно или неявно, т.е. фактически не управлять. Неявно транзакция открывается при начале изменения данных. Закрывается неявно при закрытии сессии и в некоторых других случаях. Другое дело, что некоторые клиентские программы (библиотеки доступа и т.п.) могут отслеживать эти вещи и указывать программисту, что надо бы с этим как то определиться.
В оракле например можно зайти стандартной программой SQLPlus и всю сессию работать в одной транзакции (ну насколько ресурсов хватит) если явно не давать commit или rollback. Это не значит, что так НАДО, делать, но так МОЖНО делать. Транзакцию НЕЯВНО завершает либо любой DDL запрос либо закрытие сессии.

> К типичным примерам можно отнести механизмы триггеров, контроля ссылочной целостности

А что тригер работает в контексте каких то своих особых транзакций? Мне всегда казалось что в контексте текущей. Иначе работа была бы невозможна. Именно поэтому, насколько я помню, в оракле например нельзя в теле тригера явно управлять транзакциями - он просто не откомпилируется. Можно запустить автономную транзакцию, но это другая тема.
И в ХП также (если и возможно синтаксически) не надо управлять транзакциями, ибо ХП могут вызываться как автономно таки в составе других ХП или из других мест пакетно. Поэтому рулить транзакциями надо ТОЛЬКО из клиента или самого верхнего уровня ХП если запуск происходит например из джоба.

> Контроль транзакций, в контексте которых такие алгогритмы выполняются, НЕЛЬЗЯ осуществлять извне (с клиента).
Как это? Если я удалил накладную (и соответственно все ее соствляющие) это нельзя откатить?

← →
MsGuns © (2009-02-27 10:33) [44]

>Sergey13 © (27.02.09 10:12) [43]
>Блин, Серый, мне кажется, что ты истины эти "прописные" придумал тоже тут. 8-)

Куда и когда ехать за нобелевкой ? :)

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

Неужели ?
У процессора тоже нет никакой алгоритмика - как же жто он, зараза, работает ?

Сервер выполняет не только команды, полученные от клиента, но и те, которые заложены в бизнес-логике SQL-программистом. Это уже не ПРИКЛАДНОЙ уровень, а скорее системный, т.к. не зависит от клиента. Т.е. считать "программы", заложенные в бизнес-логику, прикладными, все равно, что думать, что пассажир направляет поезд из Мухосранска в Урюпинск, а машинист, стрелочники и даже рельсы тупо исполняют его команды :)

>Единственный алгоритм сервера - ВСЕ изменения проводятся в рамках транзакций. Транзакциями >можно управлять явно или неявно, т.е. фактически не управлять.

Нельзя не управлять транзакциями. Если в программе нет явного управления, используется неявное, но используется.

>Неявно транзакция открывается при начале изменения данных.

Не обязательно. Можно послать тучу запросов на изменение и при этом транзакция не откроется, т.к. уже была открыта например селектом

>Закрывается неявно при закрытии сессии и в некоторых других случаях.

Опять не всегда. Зависит от множества факторов, влияющих на параметры соединения, например от типа курсора, способа соединения (удаленный, локальный).

>Транзакцию НЕЯВНО завершает либо любой DDL запрос либо закрытие сессии.

Вот с этим почти соглашусь

>А что тригер работает в контексте каких то своих особых транзакций? Мне всегда казалось что в контексте текущей. Иначе работа была бы невозможна.

Ну да, и я о том же

>И в ХП также (если и возможно синтаксически) не надо управлять транзакциями, ибо ХП могут >вызываться как автономно таки в составе других ХП или из других мест пакетно. Поэтому рулить >транзакциями надо ТОЛЬКО из клиента или самого верхнего уровня ХП если запуск происходит >например из джоба.

А вот это уже твое ИМХО, причем весьма спорное. Есть апологеты выноса на сторону сервера всего чего только возможно - в этом случае управление транзакциями выполняется явно там, где это необходимо средствами сиквеля.

>> Контроль транзакций, в контексте которых такие алгогритмы выполняются, НЕЛЬЗЯ >>осуществлять извне (с клиента).

>Как это? Если я удалил накладную (и соответственно все ее соствляющие) это нельзя откатить?

Нет, это значит что если ты откатываешь накладную, то не сможешь "отменить" возврат товара на карточку, если таковая операция была предусмотрена, например, триггером. Т.е. коррекция остатка выполняется АВТОМАТИЧЕСКИ сервером без всякой санкции на то клиента. Это и имелось в виду

← →
Игорь Шевченко © (2009-02-27 11:07) [45]

> >Неявно транзакция открывается при начале изменения данных.
>
>
> Не обязательно. Можно послать тучу запросов на изменение
> и при этом транзакция не откроется, т.к. уже была открыта
> например селектом

Это в какой СУБД такое ? И что за SELECT, который "открывает транзакцию" ?

← →
Sergey13 © (2009-02-27 11:13) [46]

> [44] MsGuns © (27.02.09 10:33)
> но и те, которые заложены в бизнес-логике SQL-программистом

ИМХО у тебя какое то обожествление этой "бизнес-логики". Если я некоторые свои приблуды вынесу в DLL-ку, то эта DLL-ка будет уже системной?

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

Именно это я и имел в виду. "фактически не управлять" относилось к программисту, раз он явно не прописал коммит/ролбэк.

> т.к. уже была открыта например селектом
Это свойство ИБ (может и не только) - транзакция на чтение, а не всех серверов, насколько я знаю.

> Вот с этим почти соглашусь
Ну хоть что-то! 8-)

> А вот это уже твое ИМХО, причем весьма спорное.
Этого я никогда не отрицал! 8-)

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

← →
Johnmen © (2009-02-27 11:16) [47]

> Игорь Шевченко © (27.02.09 11:07) [45]

Это не уровень сервера, это уровень клиента. Который неявно вполне себе может (и даже должен в отсутствии явного указания) стартовать тр-ю при (перед, ес-но) выполнении селективного, да и любого другого запроса.

← →
Johnmen © (2009-02-27 11:19) [48]

> MsGuns © (27.02.09 10:33) [44]
> Вот с этим почти соглашусь

Напрасно, что согласишься. И "почти" какое-то вялое...:)

← →
Игорь Шевченко © (2009-02-27 11:30) [49]

Johnmen © (27.02.09 11:16) [47]

Что написано в MsGuns[44]

">Неявно транзакция открывается при начале изменения данных.

Не обязательно. Можно послать тучу запросов на изменение и при этом транзакция не откроется, т.к. уже была открыта например селектом"

Что написано тобой:

> Это не уровень сервера, это уровень клиента. Который неявно
> вполне себе может (и даже должен в отсутствии явного указания)
> стартовать тр-ю при (перед, ес-но) выполнении селективного,
> да и любого другого запроса

Я понимаю что сколько СУБД, столько и механизмов, но давай в таком случае СУБД конкретизировать, договорились ?

Потому что, например, для Оракла высказывание MsGuns[44] неверно.

← →
MsGuns © (2009-02-27 11:32) [50]

>Игорь Шевченко © (27.02.09 11:07) [45]
>Это в какой СУБД такое ? И что за SELECT, который "открывает транзакцию" ?

В любой.
Типичный пример для ХП когда идет выборка селектом и для каждой считанной записи выполняется некая обработка, в том числе и изменяющая данные в таблицах.
Транзакция открывается (если, конечно, не была открыта ранее) непосредственно перед началом выборки.

← →
MsGuns © (2009-02-27 11:38) [51]

>Потому что, например, для Оракла высказывание MsGuns[44] неверно.

Не верю (с)
Иначе я дурак либо одно из двух :)

получается что ежели я перед изменением чего-то там выбираю данные из базы, то никакой транзакции нема, а вот когда ПО ЭТИМ ВЫБРАННЫМ записям начинаю делать апдэйты, то как бы транзакция стратует. Эге ж ?
Тогда, внимание, вопрос ! А кто же мне гарантирует, что данные, полученные селектом вне всяких транзакций, т.е. как бы "левые", не изменились и мои апдэйты тупо станут не корректны ?

Неувязочка у тебя какая-то :)

← →
Игорь Шевченко © (2009-02-27 11:44) [52]

MsGuns © (27.02.09 11:38) [51]

> Не верю (с)

Твое полное право не верить.

> Неувязочка у тебя какая-то :)

Неувязочка с твоими словами ? Это не страшно.

← →
MsGuns © (2009-02-27 11:48) [53]

>Игорь Шевченко © (27.02.09 11:44) [52]
>Неувязочка с твоими словами ? Это не страшно.

Неувязочка в твоих умазаключениях или сути выражения их словами - как тебе будет угодно
А страшно или нет - тебе решать

← →
Игорь Шевченко © (2009-02-27 11:58) [54]

MsGuns © (27.02.09 11:48) [53]

> Неувязочка в твоих умазаключениях или сути выражения их
> словами - как тебе будет угодно

В оракле SELECT транзакцию не начинает. Дальше ты можешь спорить, ловить неувязки сколько угодно, но SELECT в оракле от этого транзакцию не начнет.

Если говорить о любой СУБД - транзакция есть набор действий, переводящий базу данных из одного согласованного состояния в другое - откуда и куда базу данных переводит SELECT - это уже на совести утвеждающего про любую СУБД. Чем поведение СУБД при завершении такой транзакции по COMMIT отличается от поведения при завершении по ROLLBACK - это тоже на совести утверждающего про любую СУБД.

← →
Johnmen © (2009-02-27 12:01) [55]

> Игорь Шевченко © (27.02.09 11:58) [54]
> В оракле SELECT транзакцию не начинает.

А кто начинает?

← →
Игорь Шевченко © (2009-02-27 12:06) [56]

Johnmen © (27.02.09 12:01) [55]

Любой оператор изменения данных

← →
MsGuns © (2009-02-27 12:09) [57]

>Игорь Шевченко © (27.02.09 11:58) [54]
>В оракле SELECT транзакцию не начинает. Дальше ты можешь спорить, ловить неувязки сколько угодно, но SELECT в оракле от этого транзакцию не начнет.

Никогда и ни при каких обстоятельствах ? И глюки в апдейтах, о которых я говорил, вполне реальны ?
Или оракл насквозь глюкавый или .. ну ты понял :)

>Если говорить о любой СУБД - транзакция есть набор действий, переводящий базу данных из одного согласованного состояния в другое

Нет и еще раз нет, если под словом "согласованный" подразумевается именно "согласованный", т.е. ЛОГИЧЕСКИ корректный.

>откуда и куда базу данных переводит SELECT - это уже на совести утвеждающего про любую СУБД.

Сам селект никуда ничего не переводит, но он определяет состояние БД на некий момент, НАЧИНАЯ С КОТОРОГО ПРОГРАММИСТ МОЖЕТ БЫТЬ УВЕРЕН, ЧТО ДАННЫЕ НИКЕМ, КРОМЕ ЕГО САМОГО, ГАРАНТИРОВАННО НЕ БУДУТ ИЗМЕНЕНЫ. О чем "уведомляет" сервер явно, если все, что будет происходит после, определяется вовне на клиенте, или неявно, если все последующие действия будут выполнены в нижеследующем коде, например ХП

Ты хочешь поспорить с этим утверждением ?

>Чем поведение СУБД при завершении такой транзакции по COMMIT отличается от поведения при >завершении по ROLLBACK - это тоже на совести утверждающего про любую СУБД.

Ты сам понял что этим сказал ?

← →
MsGuns © (2009-02-27 12:15) [58]

>Блин, во избежание очередной порции критики вношу необходимую поправку:
Фразу
"О чем "уведомляет" сервер явно, если все, что будет происходит после, определяется вовне на клиенте" следует читать так:

"О чем сервер ДОЛЖЕН БЫТЬ УВЕДОМЛЕН явно, если все, что будет происходит после, определяется вовне на клиенте"

← →
Johnmen © (2009-02-27 12:24) [59]

> Игорь Шевченко © (27.02.09 12:06) [56]
> Любой оператор изменения данных

Т.е. ты утверждаешь, что селективный запрос вне транзакций, в пустоте?
Я тебя правильно понял?

← →
Sergey13 © (2009-02-27 12:24) [60]

> [57] MsGuns © (27.02.09 12:09)

> но он определяет состояние БД на некий момент, НАЧИНАЯ С
> КОТОРОГО ПРОГРАММИСТ МОЖЕТ БЫТЬ УВЕРЕН, ЧТО ДАННЫЕ НИКЕМ,
> КРОМЕ ЕГО САМОГО, ГАРАНТИРОВАННО НЕ БУДУТ ИЗМЕНЕНЫ.

Сервер выдает данные на МОМЕНТ НАЧАЛА ЗАПРОСА. Ты же не будешь утверждать, что если ты "забрал на клиента" например список подразделений, то никто его больше смотреть и менять не может, пока ты не насмотришься. Если через секунду ты повторишь свою выборку вполне можешь получить и другое состояние списка.

← →
MsGuns © (2009-02-27 12:31) [61]

>Sergey13 © (27.02.09 11:13) [46]
>ИМХО у тебя какое то обожествление этой "бизнес-логики". Если я некоторые свои приблуды вынесу в DLL-ку, то эта DLL-ка будет уже системной?

Видишь ли, в КССУБД скл-сервер играет роль, в чем-то похожую на ОС, поэтому его "бизнес-логика" весьма смахивает на СИСТЕМНЫЕ библиотеки той же винды.

Если твоя длл будет юзаться самой системой, то да, она вполне будет системной :)

← →
clickmaker © (2009-02-27 12:32) [62]

> селективный запрос вне транзакций, в пустоте?

в ms sql, например, селект может быть выполнен с хинтами. with holdlock, например, что должно гарантировать, что данные не изменятся в момент выборки. Или nolock, что ускоряет запрос, но допускает "грязное" чтение.
Тоже, по сути, вариант транзакции

← →
Игорь Шевченко © (2009-02-27 12:33) [63]

Johnmen © (27.02.09 12:24) [59]

> Т.е. ты утверждаешь, что селективный запрос вне транзакций,
> в пустоте?

Что есть "пустота" ?

← →
Johnmen © (2009-02-27 12:36) [64]

> Игорь Шевченко © (27.02.09 12:33) [63]

Пустота - это такой вакуум, где ничего и никого нет.
Т.е. ты утверждаешь, что селективный запрос вне транзакций?
Я тебя правильно понял?

← →
Игорь Шевченко © (2009-02-27 12:39) [65]

Johnmen © (27.02.09 12:36) [64]

> Пустота - это такой вакуум, где ничего и никого нет.

А солнце - шар, дающий свет.

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

Что значит "селективный запрос вне транзакций", я не понимаю твоего вопроса.

SELECT без клаузы FOR UPDATE в Оракле не инициирует начало транзации, в отличие от операторов изменения данных, в том числе к операторам изменения относится и форма SELECT ... FOR UPDATE

← →
MsGuns © (2009-02-27 12:43) [66]

>Sergey13 © (27.02.09 12:24) [60]
>> но он определяет состояние БД на некий момент, НАЧИНАЯ С
>> КОТОРОГО ПРОГРАММИСТ МОЖЕТ БЫТЬ УВЕРЕН, ЧТО ДАННЫЕ НИКЕМ,
>> КРОМЕ ЕГО САМОГО, ГАРАНТИРОВАННО НЕ БУДУТ ИЗМЕНЕНЫ.

>Сервер выдает данные на МОМЕНТ НАЧАЛА ЗАПРОСА. Ты же не будешь утверждать, что если >ты "забрал на клиента" например список подразделений, то никто его больше смотреть и менять >не может, пока ты не насмотришься. Если через секунду ты повторишь свою выборку вполне >можешь получить и другое состояние списка.

Блин, мухи, котлеты, официантка Стеллочка - все в куче.
Если моя прога на КЛИЕНТЕ стартанет ПИШУЩУЮ транзакцию на сервере, а потом будет терпеливо дожидаться пока Маша чего-там настукает на клаве, то сервер также терпеливо будет "сохранять" мне те же самые данные, которые были на старте. Что потом произойдет при коммите и на каком дереве меня за эти художества повесят - это уже не вопрос сервера
Но если прога стартует и завершает читающую транзакцию, извлекающую инфу с сервера на клиента, а затем либо одиночными запросами либо "оптом" из кэша стартует апдэйты, то эти апдэйты будут применяться к той базе, которая уже имеется на момент старта уже этой, пишущей транзакции. Со всеми возможными конфликтами, возникающие потому, что изменяемые данные, например были удалены другим клиентом.
И, наконец, весь процесс чтения и апдэйта данных завернут в бизнес логику. В этом случае клиент просто вызывает соотв-ю ХП, передавая ей что-то-там-что-нужно и ЧТЕНИЕ и ИЗМЕНЕНИЕ данных оформляются в ЕДИНОЙ быстрой транзакции, которая, конечно же, стартует по селекту.

← →
Johnmen © (2009-02-27 12:45) [67]

> Игорь Шевченко © (27.02.09 12:39) [65]
> А солнце - шар, дающий свет.

Не куб - однозначно.

> Что значит "селективный запрос вне транзакций", я не понимаю
> твоего вопроса.

Выполняется ли селективный запрос в рамках транзакции (не важно кем и когда стартованной)?
Если и так непонятно, то можно не отвечать. Я всё пойму.

← →
Игорь Шевченко © (2009-02-27 12:54) [68]

Johnmen © (27.02.09 12:45) [67]

> Выполняется ли селективный запрос в рамках транзакции (не
> важно кем и когда стартованной)?

Если выполняется после оператора изменения данных, без оператора COMMIT или ROLLBACK, то выполняется в рамках транзакции.

А что, ответа "SELECT без клаузы FOR UPDATE в Оракле не инициирует начало транзации, в отличие от операторов изменения данных"
тебе недостаточно?

Желающим поспорить советую почитать отличия версионных СУБД от блокирующих - два совершенно разных подхода к реализации механизма транзакций.

В Interbase, например, оператор SELECT начинает "транзакцию в терминах Interbase", другое дело, что под транзакцией там понимается номер версии записи, не выше которого работает оператор (или группа операторов), в Oracle механизм другой, в блокировочных (в каких-то версиях MS SQL-Server), тоже другой механизм, там читающие операторы могут заблокировать пищушие, чего нету в версионных СУБД.

Я к чему все это - к тому что нет однозначного механизма реализации транзакций и изолированности их друг от друга, и нельзя подход, применимый к одной СУБД использовать применительно к другой, можно наткнуться на аберрации поведения.

Том Кайт об этом очень популярно излагает в своих книгах про Oracle.

> Игорь Шевченко ©

Это ты Кайта начитался. Типа http://baks.gaz.ru/oradoc/ora/ora373.htm вопрос №3.
А кто такой Кайт, что спорит с разработчиками? Ну показал его пример, что якобы нет тр-ии. Я же скажу, что была, но закончилась. И что?

Я давно предполагал, что обилие всевозможных транзакций в ИБ&Ко вносит сумятицу в умы. 8-)

> [66] MsGuns © (27.02.09 12:43)
Я всегда с ИБ работал с одной пишущей транзакцией. Вернее с двумя. Одна работала на все и всегда, а вторая работала очень редко для скриптов. Просто мне так удобнее было после Оракла, где она всего одна.
И ни разу имел жалоб от клиентов на какие-то там конфликты, блокировки, замирания и т.д.
Конечно программы были не ахти какие - магазиноскладики на 3-5 пользователей максимум (обычно 2-3, но долбят клаву достаточно активно), но тем не менее все работает уже лет по 10. В основном навещаю их только при смене форм платежных документов. 8-)

...да-да, я не учел, что Кайт крут и книги пишет, а я нет...:)))

> Ну показал его пример, что якобы нет тр-ии. Я же скажу,
> что была, но закончилась. И что?

"Вынужден констатировать факт моей неоспоримой правоты в данной дискуссии, дальшейшее обсуждение считаю нецелесообразным"

> Johnmen © (27.02.09 13:28) [72]

сделай select и посмотри, появилось что-нить новое в v$transaction или нет.
насчет Кайта: по поводу крутости ничего сказать не могу, но в дезинформации вроде как замечен он не был

> Petr V. Abramov © (27.02.09 14:28) [75]
> сделай select и посмотри,
> появилось что-нить новое в v$transaction или нет.

И о чём будет говорить появление или нет?

> Johnmen © (27.02.09 14:32) [76]

стартует select транзакцию или нет.
а вообще rtfm, конечно.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2170.htm

> Johnmen © (27.02.09 14:32) [76]

http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/transact.htm#sthref602

ранее прочтения всей книжки до полного просветления не спорь с Игорем :)
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/toc.htm

> Petr V. Abramov ©

Да-да, читай. Начиная с Интродакшн. Впрочем я уже упоминал об этом...

> не спорь с Игорем :)

Очень надо...
"Занёс в дневник личных встреч" (с) оттудава же [73]

> Johnmen © (27.02.09 15:03) [79]

> Да-да, читай. Начиная с Интродакшн. Впрочем я уже упоминал
> об этом...

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

транзакции Найти похожие ветки