On 2018-05-24 01:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
So far we have following propositions:
1. Always reset external connection when it gets out of use. Close
connection if
any kind of error happens.
It actually disables connections pool for pre-v4 remote servers. It
could be
done by disabling pool in config.
I think we can be slightly more fine-grained by checking the error
code(s).
2. Always reset external connection when it gets out of use. Do not
close connection
if syntax error happens and let it to be re-used as is.
[..]
BTW, we could backport ALTER SESSION RESET into v3 and even into
v2.5: it should
just truncate GTT's and clear user context variables as pre-v4 engines
can't change
other session properties.
I think that is a good idea.
3. Never reset external connection when it gets out of use.
It also could make system work differently - when local system was
upgraded from
v3 to v4 and start to use connection pooling *and* if remote
statements depends on
session-scoped data. But in this case user could run 'ALTER SESSION
RESET' when it
is required and get correct behaviour. It requires coding discipline
and careful
planning but possible. It have no overhead on session reset when it is
not needed.
But that will be awkward, because each EXECUTE STATEMENT ON EXTERNAL
will obtain a (possibly) different connection from the pool, so an
EXECUTE doing a session reset followed by another EXECUTE could be using
different statements. This means one would have to use an EXECUTE BLOCK
that does both the session reset (will that even be possible from
execute block?) and then the other statement. I think this will make
solutions less flexible.
4. Implement EXTERNAL DATA SOURCE database object and one of its
property should
be flag to [not] reset external connection on re-use.
This is the best solution (as for me) but it might not fit into v4
release
schedule.
What did i missed ?
I disagree, I think using an unconditional session reset will be no
problem, because in existing use cases of external connections, there
won't any expectation of preserving session state. In its current form,
EXECUTE STATEMENT WITH COMMON TRANSACTION within the same transaction
will use the same connection anyway (and changing that will break
things), and across transactions, or multiple executes WITH AUTONOMOUS
TRANSACTION, the connection will be new and fresh anyway
So, there is no expectation of session preservation (outside of WITH
COMMON TRANSACTION), so we also don't need to worry about keeping it
working.
Therefor: I stand by my original proposal: unconditional session reset.
When this session reset yields a syntax error, ignore (indicates older
server version), if another error: invalidate connection.
It will behave the same as older versions, and we prevent annoying bugs
by inconsistent behaviour caused by retained session state, or wrong
expectations.
For example: it "worked" locally, as only a single user was active
locally, so it repeatedly used the same connection from the pool. When
then moved to production (or broader test environment), a solution
trying to abuse session state across EXECUTE STATEMENT ON EXTERNAL
suddenly stops working because there no longer is a guarantee that you
get the same connection.
I think we should avoid that, and make it clear: no session state across
multiple invocations of EXECUTE STATEMENT.
------------------------------------------------------------------------------
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
