19.05.2018 13:08, Mark Rotteveel wrote:
If it is global, then the permission for ALTER EXTERNAL CONNECTIONS POOL needs
to be changed:
"""
New SQL statement is introduced to manage the pool :
ALTER EXTERNAL CONNECTIONS POOL.
When prepared it desribed as DDL statement but have immediate effect: i.e.
it is executed immediately and completely, not waiting for transaction commit.
"ALTER DATABASE" permission is required to run the statement.
"""
The ALTER DATABASE privilege is per database. I don't think that a per-database privilege should be allowed to control
engine-wide configuration options. If the pool (and config) is global, I think this requires a global privilege, preferably a
separate one. If the pool **and** config is local, then it is ok.
Good point, thanks. Since the pool is global it should be guarded by global
privilege.
We could use existing MODIFY_ANY_OBJECT_IN_DATABASE or introduce a new one. For
example
MODIFY_EXTERNAL_CONNECTIONS_POOL, or ALTER_EXTERNAL_CONNECTIONS_POOL, or
something not
so long. Do you have better idea ?
We can consider a number of approaches:
1. Coarse-grained privilege that also allows changing other engine config
options exposed in DDL: ALTER_ENGINE_CONFIG.
I think this is currently the only statement that allows for changing the engine config through DDL, but this would future-proof it.
On the other hand, this could become such a wide privilege that maybe that user should simply have the RDB$ADMIN role instead.
It could be too wide, agree. Also, i don't want to mix engine config theme
here.
It could be discussed separately with all required details. And applied to the
all
involved subsystems, not only external connections pool.
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.
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). Next step could be to implement external pool as
database object and allow user to CREATE\ALTER\DROP multiply pools. 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 ?
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.
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
