date:20180520


20.05.2018 19:14, Dimitry Sibiryakov wrote:

20.05.2018 17:29, Vlad Khorsun via Firebird-devel wrote:

   Where do you see it ?


   You are right, it is nowhere in main tree. Sorry, I missed it up with one of 
my branches.
   In any case it is easy to add cache object to ConfigImpl constructor. 
ConfigFile is ready for that.



  I don't think engine is ready to deal with changing on the fly config.
In any case - this topic is not about manage of configuration.

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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 17:29, Vlad Khorsun via Firebird-devel wrote:

   Where do you see it ?


  You are right, it is nowhere in main tree. Sorry, I missed it up with one of 
my branches.
  In any case it is easy to add cache object to ConfigImpl constructor. ConfigFile is 
ready for that.


--
  WBR, SD.

--
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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 14:11, liviuslivius wrote:

Hi,

can i ask why this is only for external connections? 2 databases. One user run execute statement on database 1 from 2 second on 
database 2 from 1. Third connect simply to database 1 why it can not benefit from pool?


  Explain, please. The statement above could be understood in many different 
ways.

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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 17:53, Dimitry Sibiryakov wrote:

20.05.2018 16:25, Adriano dos Santos Fernandes wrote:

Isn't (some parts of) the config file already reloaded sometimes (timeout)?


   Firebird.conf is reloaded when its timestamp changed. Plugins' configs are 
not reloaded.


  Where do you see it ? I see ConfigCache::checkLoadConfig() only and it is used
with aliasesConf() only. I.e. databases.conf (and its includes) is reloaded when
necessary. What i am missing ?

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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 14:15, Mark Rotteveel wrote:

On 20-5-2018 13:00, Vlad Khorsun via Firebird-devel wrote:

   I plan to introduce new database object "EXTERNAL DATA SOURCE" since initial
implementation of EXECUTE STATEMENT ON EXTERNAL, but I never have time\priority
to implement it, unfortunately.

   The question at this topic is: should we add some way to clear session state 
when
connection is known to be reused ? If yes - how it should be seen by a user (SQL
statement, API call, both ?)


I can think of use cases where clearing session state can be useful (eg connections in a application-side connection pool), and I 
think exposing it as SQL should be OK, as that will give more flexibility in use. I would expect this to work with execute immediate 
(but also using prepare/execute).


  Ok, SQL statement, accounted


I would expect such a feature to reset all session state to the initial state 
on connect, including things like

* Clear context USER_SESSION
* Reset role to the initial role specified on attach
* Reset other session configuration (eg DECFLOAT behavior, timeouts, session 
timezone, etc)


  Clear GTT's also.

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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 14:13, Dimitry Sibiryakov пишет:

20.05.2018 13:00, Vlad Khorsun via Firebird-devel wrote:
   I'd suggest to add to EDS an option to use "isolated" connection, which is guaranteed the connection to be new and after use 
to be deleted, not returned to pool.


   Why one should need it ? If one don't want to use pool - just disable it.


   For example, if there is a routine for adding a user to remote database which use SET ROLE RDB$ADMIN for temporary bust of 
privileges. It won't be a good idea to leave such connection in pool for reuse. But such single routine is not a reason to disable 
pool for whole server.


  Very special case. And there is no reason to delete good connection.
Much metter is to re-initialize it automatically (as we discuss currently).


  The question at this topic is: should we add some way to clear session state 
when
connection is known to be reused ? If yes - how it should be seen by a user (SQL
statement, API call, both ?)


   SQL statement (something like ALTER SESSION RESET) is fine for me.


  Accounted

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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 16:25, Adriano dos Santos Fernandes wrote:

Isn't (some parts of) the config file already reloaded sometimes (timeout)?


  Firebird.conf is reloaded when its timestamp changed. Plugins' configs are 
not reloaded.


--
  WBR, SD.

--
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

Re: [Firebird-devel] RFC: External Connections Pool

2018-05-20 Thread Adriano dos Santos Fernandes

On 20/05/2018 09:01, Vlad Khorsun via Firebird-devel wrote:

> 
>   Cause i needed a some way to manage pool at runtime, without server
> restart,
Isn't (some parts of) the config file already reloaded sometimes (timeout)?


Adriano

--
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

Re: [Firebird-devel] Time zone feature documentation

2018-05-20 Thread Adriano dos Santos Fernandes

On 20/05/2018 08:25, Mark Rotteveel wrote:
> On 11-5-2018 18:31, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> Here is the first README version for the time zone feature.
>>
>> https://github.com/FirebirdSQL/firebird/blob/work/time-zone-support/doc/sql.extensions/README.time_zone.md
>>
>>
> 
> Will it be possible to set the session timezone on connect through a DPB
> property?

Sure, it's in my plan to add it, specially because it then is changed
before ON CONNECT triggers.


Adriano


--
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

Re: [Firebird-devel] FBJava plugin issues

2018-05-20 Thread Adriano dos Santos Fernandes

On 18/05/2018 15:59, Chmakov, Vladimir wrote:
> Hello Mark,
> 
> Here it is what we did in details:
> 
> 1) Install plugin into C:\Firebird_Java\fbjava-1.0.0-alpha-1.

I advice to prefer use the version of master instead of alpha-1.

Yes, it's not released as binary yet, but important fixes and many
changes has done since then.

I will build and publish it when time permits.

Adriano

--
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

Re: [Firebird-devel] RFC: External Connections Pool


On 20-5-2018 14:01, Vlad Khorsun via Firebird-devel wrote:
   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.


Ok, but I think in the longer term, we may want to consider to make DDL 
to control engine/server configuration to be durable (that is persistent 
across restarts).


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

Re: [Firebird-devel] RFC: External Connections Pool

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

Re: [Firebird-devel] Time zone feature documentation


On 11-5-2018 18:31, Adriano dos Santos Fernandes wrote:

Hi!

Here is the first README version for the time zone feature.

https://github.com/FirebirdSQL/firebird/blob/work/time-zone-support/doc/sql.extensions/README.time_zone.md



Will it be possible to set the session timezone on connect through a DPB 
property? I like the flexibility of statements like `SET TIME ZONE`, but 
having to execute a number of statements immediately after connect to 
establish a consistent session configuration is overhead I'd prefer to 
have to do without.


This question can be taken broader than just set time zone, as I guess 
it should also apply to things like the DECFLOAT bind and error 
configuration.


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

Re: [Firebird-devel] RFC: External Connections Pool


On 20-5-2018 13:11, liviuslivius wrote:

Hi,

can i ask why this is only for external connections? 2 databases. One 
user run execute statement on database 1 from 2 second on database 2 
from 1. Third connect simply to database 1 why it can not benefit from pool?


Do you mean a user establishing a local connection to database 1 on the 
same host as the Firebird server itself?


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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 13:11, liviuslivius wrote:
can i ask why this is only for external connections? 2 databases. One user run execute 
statement on database 1 from 2 second on database 2 from 1. Third connect simply to 
database 1 why it can not benefit from pool?


  For achieving that the implementations of pools must be moved from engine to Y-valve 
which is too complex.



--
  WBR, SD.

--
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

Re: [Firebird-devel] RFC: External Connections Pool


On 20-5-2018 13:00, Vlad Khorsun via Firebird-devel wrote:
   I plan to introduce new database object "EXTERNAL DATA SOURCE" since 
initial
implementation of EXECUTE STATEMENT ON EXTERNAL, but I never have 
time\priority

to implement it, unfortunately.

   The question at this topic is: should we add some way to clear 
session state when
connection is known to be reused ? If yes - how it should be seen by a 
user (SQL

statement, API call, both ?)


I can think of use cases where clearing session state can be useful (eg 
connections in a application-side connection pool), and I think exposing 
it as SQL should be OK, as that will give more flexibility in use. I 
would expect this to work with execute immediate (but also using 
prepare/execute).


I would expect such a feature to reset all session state to the initial 
state on connect, including things like


* Clear context USER_SESSION
* Reset role to the initial role specified on attach
* Reset other session configuration (eg DECFLOAT behavior, timeouts, 
session timezone, 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

Re: [Firebird-devel] RFC: External Connections Pool


20.05.2018 13:00, Vlad Khorsun via Firebird-devel wrote:
   I'd suggest to add to EDS an option to use "isolated" connection, which is guaranteed 
the connection to be new and after use to be deleted, not returned to pool.


   Why one should need it ? If one don't want to use pool - just disable it.


  For example, if there is a routine for adding a user to remote database which use SET 
ROLE RDB$ADMIN for temporary bust of privileges. It won't be a good idea to leave such 
connection in pool for reuse. But such single routine is not a reason to disable pool for 
whole server.



  The question at this topic is: should we add some way to clear session state 
when
connection is known to be reused ? If yes - how it should be seen by a user (SQL
statement, API call, both ?)


  SQL statement (something like ALTER SESSION RESET) is fine for me.

--
  WBR, SD.

--
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

Re: [Firebird-devel] RFC: External Connections Pool

2018-05-20 Thread liviuslivius

Hi,
can i ask why this is only for external connections? 2 databases. One user run 
execute statement on database 1 from 2 second on database 2 from 1. Third 
connect simply to database 1 why it can not benefit from pool?

Regards,Karol Bieniaszewski
null--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdotFirebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] RFC: External Connections Pool


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

Re: [Firebird-devel] RFC: External Connections Pool

20.05.2018 12:38, Dimitry Sibiryakov wrote:

19.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:

Nothing special was done in this area - GTT contents will be preserved.
The same for context variables.

So, we have a question - should we clear session-level state when connection
become unused (or when it about to be re-used) ?

I'd suggest to add to EDS an option to use "isolated" connection, which is guaranteed the connection to be new and after use to
be deleted, not returned to pool.

Why one should need it ? If one don't want to use pool - just disable it.

Or, better yet, create a table of "dblinks" which can be used as EDS and add this option as a flag to the table. With this table
database developer/administrator can decide when using or not using of pool. It may have other usages as well: simplify ES ON EDS
syntax, allow to preset (and hide) connection credential, limit usage of EDS to chosen users, etc.

I plan to introduce new database object "EXTERNAL DATA SOURCE" since initial
implementation of EXECUTE STATEMENT ON EXTERNAL, but I never have time\priority
to implement it, unfortunately.

The question at this topic is: should we add some way to clear session state
when
connection is known to be reused ? If yes - how it should be seen by a user (SQL
statement, API call, both ?)

Regards,
Vlad

Re: [Firebird-devel] RFC: External Connections Pool

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

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.

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?

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 changed external
connection pool lifetime from to ; 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

Re: [Firebird-devel] RFC: External Connections Pool


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.



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


Having a monitoring table for these would be good.

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?


Maybe this is something that needs to be deferred until this feature has 
seen some use?



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.


Another thought, I think this may be something that needs to be logged 
in firebird.log (eg   changed external connection pool 
lifetime from  to ;   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.


Other questions I have:
1. What happens if the pool configuration is done through DDL? Will it 
persist in the firebird.conf (or engine13.conf)? Will a restart of 
Firebird clear it again?


2. How will the pool work in case of Classic Server? Will pool config 
changes apply to all processes?


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

Re: [Firebird-devel] RFC: External Connections Pool