28.05.2018 16:45, Vlad Khorsun via Firebird-devel wrote:
On one hand third option would be consistent with behavior of isc_detach_database()
on client. On the other hand server cannot handle such error and it will result in
endless transaction with all consequences.
Not sure i understand you, explain please.
Currently when isc_detach_database() is called with some transaction(s) active, it yeld
an error "cannot disconnect database with open transactions" which is exactly what you
have suggested for reset. How are you going to handle this error in pool's code?
I personally hate current isc_detach_database() behavior because there is no sane way
to handle the error by code, so I would vote for the second option: rollback transaction
(and may be issue/log a warning).
What is sane way, for you ?
Take decision to commit or rollback active transactions. But right code already does it
before disconnect, so the only way to get the disconnect error is a bug which loose
transaction handle. Without handle, transaction rollback with isc_rollback_transaction()
is impossible.
Do you aware of fb_cancel_operation(fb_cancel_abort) ?
No. This function is new for me.
--
WBR, SD.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
