On 19-5-2018 17:11, Vlad Khorsun via Firebird-devel wrote:
19.05.2018 13:08, Mark Rotteveel wrote:
2. Fine-grained privilege that applies only to this single option:
ALTER_EXTERNAL_CONNECTIONS_POOL or if shorter is preferred:
ALTER_EXT_CONN_POOL
3. In addition to option 2, maybe allow even finer-grained control, eg
support granting people only the privilege to clear the pool, but not
change the config: privilege CLEAR_EXT_CONN_POOL (or something like
that).
It looks as not necessary as pool could be cleared by setting its
size to zero.
You are missing my point: this privilege is about giving a user/role the
right to clear the pool from its current connections, while at the same
time not allowing those users to change the configuration like pool
size, lifetime, etc.
We may need to consider doing all three.
So far i see only (2) as necessary change.
Also, i want to speak about possible extension of the feature. I
think it would
be good to have new monitoring table with list of all external
connections. Not
sure if we should allow to DELETE here but it should be at least
considered too.
It will replace two of four new context variables
(EXT_CONN_POOL_IDLE_COUNT and
EXT_CONN_POOL_ACTIVE_COUNT).
Having a monitoring table for these would be good.
Next step could be to implement external
pool as
database object and allow user to CREATE\ALTER\DROP multiply pools.
At the moment, I don't really see the use case of being able to define
multiple pools (and how you would then use them). How do you envision
this feature works?
Maybe this is something that needs to be deferred until this feature has
seen some use?
Another little
improvement could be new property of pooled connection - recycle time.
It means that
even if connection is actively used it should be closed after "recycle
time" (of
course when it become inactive).
What do you think ?
Limiting the lifetime of a connection in the pool. Yes, that is a good
idea. In the Java world, this property is usually called something like
maximum connection lifetime.
Another thought, I think this may be something that needs to be logged
in firebird.log (eg <date> <username> changed external connection pool
lifetime from <oldvalue> to <newvalue>; <date> <username> cleared
old|all connections, etc)
Another setting to enable\disable such logging ? Please, no ;) It
would be much
better to discuss (separately, yes) how logging could be structured and
moved to
the public interface\new plugin, IMHO.
I said nothing about having settings for enabling or disabling said
logging, I think changes to the configuration need to be logged, so they
can be audited.
Other questions I have:
1. What happens if the pool configuration is done through DDL? Will it
persist in the firebird.conf (or engine13.conf)? Will a restart of
Firebird clear it again?
2. How will the pool work in case of Classic Server? Will pool config
changes apply to all processes?
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
