Симонов ДенисПо третьему - возможно надо получать подтверждение из клиента, т.е. обработать как-то чтобы транзакция или запрос при желании могли быть продолжены. Если конечно он не на разрыв коннектаЕсли инициатор отмены - клиент, то, технически, можно сделать колбеки до и после отмены.
Симонов ДенисХотя возможно это уже переборВот-вот :)

Если же отмена возникает на сервере, то я не думаю, что он должен консультироваться с клиентом.

Dimitry SibiryakovЯ очень сильно надеюсь , что никому не придёт в голову возвращать ошибку из
isc_rollback_transaction() при попытке отката уже убитой транзакции.А почему, собственно ты так сильно на это надеешься ?
Как по мне, тут самое место ошибке isc_bad_tra_handle (ну или isc_cancelled, если это будет возможно).

Dimitry SibiryakovПотому что в документации по IB API недвусмысленно написано "isc_rollback_transaction()
никогда не обламывается и гарантированно завершает транзакцию". И это правильноЯ не говорю, что это не правильно.
Я хочу аргументов, а не бла-бла вроде:Dimitry Sibiryakovв чём я имел возможность убедиться на обратном примере с ODBC
Ибо завтра ты будешь утверждать обратное, а у меня не будет аргументов :)

Dimitry Sibiryakov,

и какие проблемы влечёт за собой isc_bad_trans при попытке сделать роллбек несуществующей тр-ции ?

Dimitry SibiryakovСначала возникает недоумение: "и что мне теперь делать"Обнулить своё хендл тр-ции и отпустить связанные с ней ресурсы.
Dimitry SibiryakovЧто, собственно, и равноценно вообще отсутствию ошибки.Тебе равноценно - игнорируй её. Но не заставляй других делать каку...

Dimitry SibiryakovЯ очень сильно надеюсь , что никому не придёт в голову возвращать ошибку из
isc_rollback_transaction() при попытке отката уже убитой транзакции.Ну как, прошло ?

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

Конструктив есть, или ты опять упёрся ?

Dimitry SibiryakovВ вышеприведённом
коде если обработать ошибку и выкинуть исключение из RollbackТ.е. ты озаботился вод таким вот кодом (с IBX\FIB+\etc)


Да ?

1. Этот код изначально не полон, т.к., тут не определена реакция на исключение в Rollback.
Например, IBTransaction.Rolback может вызвать исключение даже до самого роллбека, ибо он вызывает кучу пользовательских событий (BeforeTransactionEnd).
Но даже если мы забьём на вышесказанное и поклянёмся никода не кидать исключения в BeforeTransactionEnd, то

2. Кто заставляет метод Rollback высокоуровневой (!) компоненты кидать исключение при обнаружении isc_bad_trans, а не обработать его более цивилизованно ?

В моей очень старой копии IBDatabase.pas, например, есть обработка ошибки isc_network_error с вызовом DefaultDatabase.ForceClose (я уже сам успел забыть об этом и немало удивился, когда это сейчас обнаружил)

Dimitry SibiryakovДа, и кстати о таймаутах на транзакцию и коннект: вот есть приложение, оно соединилось с
базой и что-то там себе делает. К базе не обращается . Вообще. В какое место вы
собираетесь пихать ошибку таймаута?Коннект разорвётся по истечении таймаута. А вот приложение узнает об этом
- при попытке что-то сделать в коннекте
- если мы сделаем спец. колбек и приложение зарегистрирует его обрабтчик - то сразу


Dimitry SibiryakovЧуть посложнее задача: приложение соединилось с базой, подписалось на события и что-то там
себе делает. К базе опять же не обращается . Собираетесь ему обломать всю
малину или только первичный коннект?Это можно обсудить.
Сходу - я бы не стал для обрубать коннект во время ожидания ивентов.

dimitr,

одно дело категорично кричать что нужно сделать только так и никак иначе, а другое обсуждать с аргументированием своей позиции (что камрад Сибиряков начал делать со скрипом и только из-под палки :)