24.05.2018 12:01, Mark Rotteveel wrote:
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).
And (2) below is exactly about it
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.
Accounted
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.
Ignored, as you wrote in another mesage.
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
After first execution of EXECUTE STATEMENT WITH COMMON TRANSACTION the remote
connection is bound with local one and all next EXECUTE STATEMENT WITH
AUTONOMOUS
TRANSACTION will use the same connection, until local transaction end.
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.
To be more exact: there is no expectation if session preserved state and
no expectation if session not preserved state.
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.
This is described above as (2) and I going to implement it this way. While I
still consider it as not best possible solution, it looks easyest for end users.
The best could be (4) but I am not sure it could be implemented and tested
enough
in v4 timeframe.
It will behave the same as older versions, and we prevent annoying bugs by inconsistent behaviour caused by retained session state,
or wrong expectations.
It can't behave the same as older versions as older versions have no
connection pool.
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.
We can't make such statement. Older engine can't reset session state.
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
