On 23-5-2018 14:20, Vlad Khorsun via Firebird-devel wrote:
23.05.2018 13:48, Mark Rotteveel wrote:
On 23-5-2018 11:24, Vlad Khorsun via Firebird-devel wrote:
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external
connections.
The feature was initially developed more than a year ago, and works
at production
with good feedback.
According to discussion in this topic i made following changes:
- New system privilege MODIFY_EXT_CONN_POOL to manage pool properties
(instead of
initiallly used 'ALTER DATABASE' user right).
- 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?
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.
doc\README.session_idle_timeouts:
--------
- idle session timeout could be set:
- at database level, by setting value in firebird.conf (or
databases.conf) by database
administrator
...
- effective value of idle timeout is evaluated every time user API call
leaves the engine
as:
- if not set at connection level, look at database level
--------
doc\README.statement_timeouts
--------
- timeout value could be set:
- at database level, by setting value in firebird.conf (or
databases.conf) by database
administrator
...
- effective value of timeout is evaluated every time statement starts
execution
(or cursor is opened) as:
- if not set at statement level, look at connection level
- if not set at connection level, look at database level
--------
Ok, so it is not possible to pre-configure the connection-level
configuration in the DPB?
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.
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.
One more question: can ALTER SESSION RESET be executed without an active
transaction?
Mark
--
Mark Rotteveel
------------------------------------------------------------------------------
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
