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.
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?
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). You might want to consider if it can be executed
asynchronously (eg execute on check-in, read response on check-out,
decide if error response invalidates connection or not?).
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.
- At tracker there was proposition to add new database trigger ON RESET
which should
fire when ALTER SESSION RESET is run. Should we implement it ?
I suggest to call it ON SESSION RESET (or ON SESSION_RESET) instead of
ON RESET.
- If i missed something else - please tell me.
Please, read and comment:
https://github.com/FirebirdSQL/firebird/blob/ExternalConnectionsPool/doc/sql.extensions/README.external_connections_pool
It was updated according to suggestions in this topic.
I see a number of typos, but maybe I'll propose a pull request for those
if I can find the time.
--
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
