On 4-6-2018 11:49, Vlad Khorsun via Firebird-devel wrote:
02.06.2018 19:54, Mark Rotteveel wrote:
JDBC API requires that statements are executed in a transaction. In
theory I can break that rule, but the problem with that is that it
requires explicit handling, which is 1) annoying to do and 2) brittle
given the other API requirements involving transactions; and given my
current health issues I don't see myself implementing that anytime soon.
And no, Jaybird has no specific handling for SET TRANSACTION, because
the JDBC API specifies that users should use the methods defined in
the API for things like transaction configuration, etc.
All above is a good explanation why generic\universal API is bad :)
Uhm, no. Generic APIs like JDBC allow tools and libraries to work with
your database without having been specifically developed for your
database, which especially for Firebird is quite helpful.
BTW, looks like implicit transaction start (not supported by Firebird)
could solve this issues, agree ?
It could make things easier, yes, although at the same time I also see
issues with its design.
_"all new session management statements could run with no transaction
context."_
There is a big difference between _could_ and _must_.
For flexibility sake, especially in the light of drivers whose API
makes it harder to execute transaction-less (Jaybird and Firebird
ADO.net, but AFAIK also FDB/pyfirebirdsql, possibly others), Firebird
should allow execution of these statements in a transaction.
Don't you think that 3 API calls where just one is enough not looks
perfect ?
I agree it is not perfect, but that is the world we live in.
Well, i understand your point and will not argue against it (while
nor like it
nor agree with it).
Consider returning a warning if execution of ALTER SESSION RESET
occurs within a transaction. If you must restrict it to only a single
active transaction that's fine.
Such warning is useless. Users will never read it. Engine not benefit
from it too.
JDBC and Jaybird has specific support for warnings, and I think a
warning should be issued here.
I could even live with a rule that this must be the first statement of
a transaction (maybe even with requiring it to be the only statement
of a transaction).
What do you think if engine will internally rollback immediately
before reset
and start new transaction (with the same properties as old one) after
reset ?
Transaction handles will not be changed. I.e. for end user it looks like
rollback
retaining but not retains old context.
I think this is OK, if it is coupled with a warning.
As an aside, the sqlstate is 01002 is warning(!) "disconnect error"
according to the SQL standard, I don't think that state is suitable here.
This is exactly the same state that used for isc_open_trans error on
detach.
Sure, but there it **is** a "disconnect error" (although, not a warning
:) the SQL standard is a bit vague if warning sqlstates can also be used
for errors or not).
Note that on disconnect, I could actually live with Firebird rolling
back active (not-prepared) transactions ;)
Mark
--
Mark Rotteveel
------------------------------------------------------------------------------
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
