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 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
--------
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).
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?).
At first look it adds a lot of complexity at engine level as currently we
don't
support such processing at remote protocol. I.e. it can't be implemented
directly
as you say above. We could put connections to be reset into another list at the
pool and process this list by another thread... don't know how much it will
affect
release schedule of v4...
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.
- 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\when we will agree to implement it - i will not object.
- 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.
I'll check it once more time, thanks
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