Господа,
порой встречается подобный код:

begin transaction
update table
commit transaction

Интересно зачем создавать транзакцию для одного запроса.

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

Зачем-же так пишут? Дань традиции? Стиль других СУБД?

Заранее спасибо

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

Транзакции для одного запроса имеют смысл в режиме chained mode, т.к.
в нём если есть несколько запросов и какой-нибудь из них не сработает, то откатится всё.
Если же каждый запрос поместить в отдельную явную транзакцию, то такого не произойдёт.

В общем, в процедурах имеет смысл, что бы сделать их более устойчивыми к настройкам сессии.

Господа, большое спасибо за отклик.
В теории оно вроде понятно, но как объяснить следующее?...


создаём табличку, уникальный индекс и 2 процедуры, написанные так, чтобы 1й запрос прошёл и второй завершился ошибкой

В isql сессии ставим set chained off и выполняем обе процедуры - результат одинаковый - 1я запись вставляется, вторая нет (в силу ошибки)

открываем 2ю сессию и ставим set chained on
выполняем 1ю процедуру (содержащую транзакции) - всё отрабатывает и транзакция автоматически коммитится (что довольно интересно и идёт вопреки с теорией вложенных транзакций)

выполняем теперь процедуру без транзакций - мы видим, что она выдаёт сообщение
Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK TRAN is
missing. Previous count = 0, Current count = 1.

Может багафича - не знаю, но процедура содержащая транзакции оказывается работоспособной в любом режиме, в то время как процедура без транзакций в chained mode уже не работает.


Я создавал процедуры как в Артизане, так и в isql. На результат этот не повлияло.

Может кто-нибудь повторить мой тест?
Какие соображения почему так происходит?

Заранее спасибо

Большое спасибо за отклик.
Позволю себе не согласиться.
White OwlНичего не вопреки.
В цепочном режиме главная транзакция открывается на первой же команде - в данном случае на вызове процедуры. Транзакции внутри процедуры уже являются вложенными. А commit принадлежащий вложенной транзакции всего-лишь уменьшает счетчик вложений и ничего не коммитит в реальности. Читай главу Nested Transactions еще раз, самый первый абзац :)


Читал.
Вот фрагмент из определения вложенных транзакций
авторYou can nest transactions within other transactions. When you nest begin transaction and commit transaction statements, the outermost pair actually begin and commit the transaction. The inner pairs just keep track of the nesting level. Adaptive Server does not commit the transaction until the commit transaction that matches the outermost begin transaction is issued

Но процедура ведёт себя именно вопреки!

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

Открытая цепным режимом транзакция должна будет ждать своего завершения, но именно этого и не просиходит когда в процедуре используются транзакции * (см несколько комментариев ниже)

То что происходит - это каким-то образом закрывается и внешняя транзакция, при этом всегда с коммитом.

Это поведение -то и противоричит тому что в доке написано.

Не верится - попробуйте сами.

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

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


По поводу глупости использования транзакций в процедурах - я бы небыл столь категориченым.

Разные бывают решения, но конечно код со вложенными транзакциями сложнее поддерживать.

Зачем это нужно - ну вот пример в данном топике показывает что процедура с транзакциями ведёт себя в цепном режиме по другому.

MasterZiv
Kru wrote:

Ребята, процедуры никак транзакциями не управляют.
Максимум что может быть это в chained mode при вызове
процедуры неявно начнётся транзакция.
Всё. Коммитить её в любом случае надо руками.

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

White Owl
Используя твои процедуры в цепочном режиме, делаем:
Вопросы? :)


Не совсем.
Попробуйте сделать 2 процедуры - в обеих Insert в какую-нибудь dummy табличку, но только в 1й процедуре этот insert вложите в явную транзакцию.
Попробуйте выполнить их в chain mode.
Расскажите, была ли разница? По идее 1я процедура должна завершиться автокоммитом, в то время как 2я (без явной транзакции), завершится сообщением о висячей транзакции.

Если удастся это воспроизвести, то станет сразу ясно, о чём речь идёт.
С чего это вдруг, 1й случай автокоммитится, а второй нет? Если на клиенте автокоммит не установлен, то незакрытая транзакция должна оставаться незакрытой в обоих случаях, ну а если установлен, то должна в обоих случаях коммитится.
Так ведь?

MasterZiv
White Owl wrote:


> Я вас записываю.


Спасибочки

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

Возникала, откатываем.

> И вообще все клиенты работают в режиме автокоммита.

Да, и НЕ управляют транзакциями.
Но вот сейчас третье звено добавляем, будут работать и так, и так.
И в chained, и в автокомите.


Так кто-нибудь попробовал воспроизвести странное поведение Sybase?

White Owl,
Большое спасибо что попробовал (давайте на ты)

На пятнашке всё правильно работает, но поверь, на 12.5.4 происходит именно автокоммит.
В нашей компании ещё один программист это подтвердил и багафичу админам на исследование отправили, т.к. пока сидим на 12.5.ххх

Для меня вопрос закрыт.

Ещё раз тебе и Мастеру огромное спасибо за участие.