23.05.2018 15:40, Mark Rotteveel wrote:
- New session management statement ALTER SESSION RESET is implemented (see
CORE-5832).
Ticket is not marked as closed for a while as i want to make sure
implementation
is complete. Thus any suggestions, notes, etc are welcome.
As I said in another mail, I think the RDB$GET/SET_CONTEXT USER_SESSION should
also be cleared.
Read ticket description once more, please, it is clearly stated there:
> - remove all context variables in 'USER_SESSION' namespace
I looked at the commit, but I don't see anything that clears the USER_SESSION.
What did I miss?
void Jrd::Attachment::resetSession(thread_db* tdbb)
{
...
// reset context variables
att_context_vars.clear();
I also noticed that you unconditionally reset the statement idleTimeout and statementTimeout to 0. Does this mean there is no DPB
property to set a connection-wide config for these options? Will setting it to 0 ignore the default config, or will it apply the
default config?
Zero at attachment level means value from the config is effective.
...
Ok, so it is not possible to pre-configure the connection-level configuration
in the DPB?
No
I still have some questions to agree (or not):
- Should connections pool always use ALTER SESSION RESET when connection become
idle ?
At first looks - yes, it should. It allows to make (almost) no difference
for user
code with non-pooled connections. But from practical POV i have some doubts
and want
to discuss it here:
- pre v4 Firebird versions have no such statement and it will fail (of course
connections pool should handle it correctly)
- it adds at least one additional network roundtrip which could be
unnecessary if
user code doesn't alter session and not uses GTT ON COMMIT PRESERVE on
remote side.
For some applications it could add too much performance penalty for nothing
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).
What other option is there? The only alternative would be to define a pool per db + user, and specify whether the connection can be
reset or not.
Additional clause at EXECUTE STATEMENT ON EXTERNAL ?
Not sure i like it
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").
I don't think the pool-side should conditionally reset the session, because 1) it becomes complex fast to check if session reset
should apply or not and 2) will disallow independent evolution of what is reset or not, nor would it be possible do additional
reset in the ON RESET trigger proposed below.
I don't offer conditional reset of the session. I offer not to do it at all
and let users to do it if really required. At least in v4. After v4 we could
introduce pools and\or external data sources as database objects and create
corresponding properties at this level.
Hmm, I'm not sure if I like that connections could potentially be in an inconsistent state as left by a different
application/database (or different 'part' of the same database). That can result in transient bugs that depend on specific order of
execution which can be a pain to debug.
If session reset is strongly required, one may issue ALTER SESSION RESET as
first
external statement in current transaction. External connection is bound to the
current
transaction (unless it uses autonomous transactions *only*).
One more question: can ALTER SESSION RESET be executed without an active
transaction?
All session management statements requires no transaction, AFAIU.
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
