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

Reply via email to