20.05.2018 12:55, Mark Rotteveel wrote:
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.
I don't miss it. I just say that privilege to clear the pool looks redundant
as
setting pool size to zero have same effect. If you insist - i can live with it.
But
i consider as not good to make new system privilege for every single task.
We may need to consider doing all three.
So far i see only (2) as necessary change.
Existing set of system privleges have no ALTER_XXX, so i think we should use
MODIFY_EXT_CONN_POOL here.
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.
Accounted, thanks.
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?
Pool will be choosed based on external database name. It could be full match
or regexp pattern. In latter case we could introduce explicit ordering used to
search what pool to use to avoid ambiguity. The main goal is to fine tune number
and lifetime of pooled connections for differefent external databases.
Maybe this is something that needs to be deferred until this feature has seen
some use?
Very probably. I want to show how i see direction of future development in
this area.
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.
I already implement idle connection lifetime but it could be useful to make
hard limit
even for connections that used actively.
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.
Please, let leave theme of how to manage configuration changes for another
discussion,
else we never finish this one. For audit we have another feature. So we could
add
corresponding events in the Trace interface.
Other questions I have:
1. What happens if the pool configuration is done through DDL?
Its runtime values are applied immediately. It is described in
README.external_connections_pool.
Will it persist in the firebird.conf (or engine13.conf)?
No.
Will a restart of Firebird clear it again?
Yes.
2. How will the pool work in case of Classic Server? Will pool config changes
apply to all processes?
Current process only. Since we have pool per process, not per whole
system\instance.
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
