23.05.2018 14:40, Mark Rotteveel wrote:
I think it should unconditionally do a session reset on return to the pool if the
protocol is v16 or higher (assuming v16 is the Firebird 4 protocol version).
This is not truly unconditionally :)
But relying on protocol version is also not perfect - remote server could be
upgraded at some moment (v3 -> v4) and whole system behaviour will be changed
(automatically and not very expectedly).
At first, at API level there is no way to find out protocol version and no easy way to
find out remote server version/capacities.
At second, there is no way to upgrade server without breaking established connection
(obviously).
At third, behavior of pooled connection must exactly match behavior of non-pooled
connection no mater what happen.
If gather all this together, IMHO, it is enough to do reset unconditionally and, if it
has failed for any reason, to mark EDS as non-pooled in metadata cache. It will eliminate
extra round-trip in cases when pooling is impossible.
As for overhead of this round-trip in pooled connection, I think that the statement can
be sent by pool in background mode after the connection is returned to it. Of course,
during this the connection won't be available for re-use, but for pool it doesn't matter
as it always can have some spare connections at hand.
I can't think of alternatives that wouldn't be complex or plain magic compared to "if
session reset is supported, perform session reset" (apart from: "never perform session
reset").
May be something like configuration parameter "force pooling" (defaulted to false) to
allow using of pool with remote servers that don't support session reset.
--
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
