20.05.2018 14:06, Mark Rotteveel wrote:
On 20-5-2018 12:47, Vlad Khorsun via Firebird-devel wrote:
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.
There is a difference between just clearing the pool, and setting the size to zero. Clearing it will just remove the current
connections (and allowing it to be repopulated), while setting the size to zero disables the pool. One has a transient effect and is
therefor less disruptive, the other will be persistent and can have significant and continuous impact on the performance
characteristics of the database server.
I understand the difference. But look from security POV: user with
MODIFY_EXT_CONN_POOL
privilege could set pool size to zero and reset it to the previous value again
and he not
need CLEAR_EXT_CONN_POOL privilege do clear the pool. I think we should avoid
such cases.
That is why I proposed an additional (more restricted) privilege. On the other hand, this may be something that we can defer until
the pool has seen some use and we have established a clear need for this.
Yes, lets defer it for a while. Introduce new system privilege is easy task
and it could
be done before final release, if necessary.
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.
Is fine with me :)
Very good. I'll commit is soon.
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.
Ok, I understand, that could be useful.
Good. Put it into the future plans
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.
Hmm, this could make for odd performance changes between restarts. This will need to be clearly documented. I would expect the
config changes done this way to be permanent.
Agree, it should be documented. Will do.
Playing devil's advocate, if this configuration change isn't persistent, why expose it as DDL at all? Especially given the
difference exposed below.
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.
Cause i needed a some way to manage pool at runtime, without server restart,
and i saw no better\easy way to do it. If you offer some - it will be considered
of course.
Pool management statements (even without persistence) allows DBA to play with
pool properties to find an optimal values and then put in into config - this was
initial idea.
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
