24.05.2018 0:39, Dimitry Sibiryakov wrote:
23.05.2018 21:18, Vlad Khorsun via Firebird-devel wrote:
At second, there is no way to upgrade server without breaking established
connection (obviously).
Nobody tell about it. And it change nothing.
Then could you, please, explain what you have on mind when said "remote
server could be
upgraded at some moment (v3 -> v4) and whole system behaviour will be changed
(automatically and not very expectedly)"?
What visible changes can happen after upgrade of server version?
We have local server v4 and remote server v3. v4 runs external statements
against v3
and remote sessions have some context that is re-used by remote statements
somehow.
Then remote server is upgraded to v4 and remote sessions gets reset on re-use.
Now
remote statements can't re-use that context and behaviour could be changed.
At third, behavior of pooled connection must exactly match behavior of
non-pooled connection no mater what happen.
So, why we discuss ON RESET trigger(s) ? ;)
I mean that user application must not be able to distinguish them. I.e. using of connection pool with default settings should
have no visible side-effects.
Ideally - yes. But real world is not ideal.
In this discussion we trying to find a way to minimize "surprizes" and allow
system to run in consistent way.
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.
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.
It *could* make system work differently and it depends on remote side
version.
If remote statements not changes session-scoped data (such as user contex
variables,
content of GTT ON COMMIT PRESERVE, etc) - such system is not affected and will
have
benefits from connections pooling.
Also, it add some dumb overhead - when remote system is pre-v4 and can't
handle
ALTER SESSION RESET or when remote statements is not changes the session-scoped
data
above. At some use cases it could be bad or very bad.
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.
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.
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 ?
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
