All,
Some update on this topic
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.
The issue that left unresolved is what to do if there is active
transaction(s) exists
at the connection about to be reset. The possible answers is:
- do nothing and reset connection
if there is active transaction that made changes of GTT ON COMMIT PRESERVE
and if it
will be rolled back (or just undo savepoint) - there will be bugcheck, as
GTT's was
reset and contains no pages
- forcebly rollback active transactions and reset connection
same as if connection was broken
- raise error and don't reset connection.
Obviously, first case is not an option and we must choose between second and
third.
So far i prefer to raise error and don't reset.
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
The committed code always reset connection and closes it if reset was failed
by any reason.
- 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 ?
There is still no agreement. Current offers:
- single ON SESSION RESET trigger
- pair of new triggers: BEFORE SESSION RESET and AFTER SESSION RESET
- use existing ON CONNECT and ON DISCONNECT triggers and introduce a way to
distinguish
true connect\disconnect from reset (for ex. new system function like
INSERTING\UPDATING\
DELETING)
I prefer to not introduce new triggers.
- 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.
Updated again.
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
