On 19-5-2018 10:43, Vlad Khorsun via Firebird-devel wrote:
19.05.2018 11:04, Mark Rotteveel wrote:
On 18-5-2018 18:44, Vlad Khorsun via Firebird-devel wrote:
...
Please, read and comment:
https://github.com/FirebirdSQL/firebird/blob/ExternalConnectionsPool/doc/sql.extensions/README.external_connections_pool
1. I'm not sure how I should read the "Key characteristic" that says:
"the pool is common for all local connections handled by the given
Firebird process"
It means that all local (user) connections requests for external
connection
are handled by the same single pool instance.
2. (maybe related to 1) What is not clear to me is whether this pool
is global (for the whole engine), or per database.
The whole engine.
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.
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).
We may need to consider doing all three.
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)
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
