28.05.2018 18:03, Dimitry Sibiryakov wrote:
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?
First, such error means some bug in pool code. Second, there is special case
for
application that should disconnect forcibly:
fb_cancel_operation(fb_cancel_abort).
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.
Good, i have the same opinion.
Do you aware of fb_cancel_operation(fb_cancel_abort) ?
No. This function is new for me.
So, its time to read README.fb_cancel_operation and\or ReleaseNotes.
It is documented since introduction at 2.5.0
Regards,
Vlad
------------------------------------------------------------------------------
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
