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.
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.
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 :)
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.
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.
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.
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
