All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback.
Some bugs was fixed since then, so it should be stable enough and definitely
good for beta release of
29.05.2018 2:06, Adriano dos Santos Fernandes wrote:
On 28/05/2018 09:13, Vlad Khorsun via Firebird-devel wrote:
There is still no agreement. Current offers:
- single ON SESSION RESET trigger
- pair of new triggers: BEFORE SESSION RESET and AFTER SESSION RESET
- use existing ON CONNECT and ON
On 28/05/2018 09:13, Vlad Khorsun via Firebird-devel wrote:
> There is still no agreement. Current offers:
> - single ON SESSION RESET trigger
> - pair of new triggers: BEFORE SESSION RESET and AFTER SESSION RESET
> - use existing ON CONNECT and ON DISCONNECT triggers and introduce a way
> to dis
28.05.2018 18:03, Dimitry Sibiryakov wrote:
28.05.2018 16:45, Vlad Khorsun via Firebird-devel wrote:
On one hand third option would be consistent with behavior of isc_detach_database() on client. On the other hand server cannot
handle such error and it will result in endless transaction with
28.05.2018 16:45, Vlad Khorsun via Firebird-devel wrote:
On one hand third option would be consistent with behavior of isc_detach_database()
on client. On the other hand server cannot handle such error and it will result in
endless transaction with all consequences.
Not sure i understand
28.05.2018 15:57, Dimitry Sibiryakov wrote:
28.05.2018 14:13, Vlad Khorsun via Firebird-devel wrote:
- forcebly rollback active transactions and reset connection
same as if connection was broken
- raise error and don't reset connection.
Obviously, first case is not an option and we must c
28.05.2018 14:13, Vlad Khorsun via Firebird-devel wrote:
- forcebly rollback active transactions and reset connection
same as if connection was broken
- raise error and don't reset connection.
Obviously, first case is not an option and we must choose between second and
third.
So far i pre
All,
Some update on this topic
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback.
Accor
23.05.2018 15:07, Adriano dos Santos Fernandes wrote:
On 23/05/2018 08:51, Vlad Khorsun via Firebird-devel wrote:
23.05.2018 13:40, Adriano dos Santos Fernandes wrote:
On 23/05/2018 06:48, Dimitry Sibiryakov wrote:
In this case I guess there must be two triggers: BEFORE RESET and
AFTER RE
> > 3.2) Implemented (2): some connection with some values in variables.
> + pool works and add big performance benefits
> + overhead executing statement that can't be handled by remote
> All works much faster than before v4.
>
> 3.3) Implemented (3): some connection with some values in variables
25.05.2018 17:51, Vlad Khorsun via Firebird-devel wrote:
I.e. all works a bit slower than before v4.
I think that it can be a good motivation to upgrade remote server to v4.
Bad joke
I was serious. I see people still use old Firebird versions. IMHO, it would be good to
offer them s
25.05.2018 18:33, Dimitry Sibiryakov wrote:
25.05.2018 17:26, Vlad Khorsun via Firebird-devel wrote:
I.e. all works a bit slower than before v4.
I think that it can be a good motivation to upgrade remote server to v4.
Bad joke
All works much faster than before v4.
Do you have som
25.05.2018 17:26, Vlad Khorsun via Firebird-devel wrote:
I.e. all works a bit slower than before v4.
I think that it can be a good motivation to upgrade remote server to v4.
All works much faster than before v4.
Do you have some numbers for this "much" to see if speed overweight support
25.05.2018 17:05, Dimitry Sibiryakov wrote:
25.05.2018 15:53, Vlad Khorsun via Firebird-devel wrote:
Remote statement could check some context variable and run this or that
branch
of code in dependence of variable value. Then it could assign another value to
this context variable. It all cou
25.05.2018 15:53, Vlad Khorsun via Firebird-devel wrote:
Remote statement could check some context variable and run this or that
branch
of code in dependence of variable value. Then it could assign another value to
this context variable. It all could be done in the single stored procedure cal
25.05.2018 16:40, Dimitry Sibiryakov пишет:
25.05.2018 15:28, Vlad Khorsun via Firebird-devel wrote:
We have local server v4 and remote server v3. v4 runs external statements
against v3
and remote sessions have some context that is re-used by remote statements
somehow.
Then remote server is
25.05.2018 15:45, Vlad Khorsun via Firebird-devel wrote:
1. Always reset external connection when it gets out of use. Close connection if
any kind of error happens.
It actually disables connections pool for pre-v4 remote servers. It could be
done by disabling pool in config.
I think we can
24.05.2018 12:01, Mark Rotteveel wrote:
On 2018-05-24 01:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
So far we have following propositions:
1. Always reset external connection when it gets out of use. Close connection if
any kind of error happens.
25.05.2018 15:28, Vlad Khorsun via Firebird-devel wrote:
We have local server v4 and remote server v3. v4 runs external statements
against v3
and remote sessions have some context that is re-used by remote statements
somehow.
Then remote server is upgraded to v4 and remote sessions gets rese
24.05.2018 12:06, Dimitry Sibiryakov wrote:
24.05.2018 10:50, Vlad Khorsun via Firebird-devel wrote:
From reading documentation I have a feeling that currently external connection is reused only within transaction. When local
transaction ends, connection is disconnected.
Yes, almost
24.05.2018 10:50, Vlad Khorsun via Firebird-devel wrote:
From reading documentation I have a feeling that currently external connection is
reused only within transaction. When local transaction ends, connection is disconnected.
Yes, almost
Am I wrong?
Yes. Above i speak about v4
On 2018-05-24 11:01, Mark Rotteveel wrote:
On 2018-05-24 01:08, Vlad Khorsun via Firebird-devel wrote:
3. Never reset external connection when it gets out of use.
It also could make system work differently - when local system was
upgraded from
v3 to v4 and start to use connection pooling *and
On 2018-05-24 01:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
So far we have following propositions:
1. Always reset external connection when it gets out of use. Close
connection if
any kind of error happens.
It actually disables connections pool
24.05.2018 11:35, Dimitry Sibiryakov wrote:
24.05.2018 1:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
What visible changes can happen after upgrade of server version?
We have local server v4 and remote server v3. v4 runs external statements
agai
24.05.2018 1:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
What visible changes can happen after upgrade of server version?
We have local server v4 and remote server v3. v4 runs external statements
against v3
and remote sessions have some context
24.05.2018 0:39, Dimitry Sibiryakov wrote:
23.05.2018 21:18, Vlad Khorsun via Firebird-devel wrote:
At second, there is no way to upgrade server without breaking established
connection (obviously).
Nobody tell about it. And it change nothing.
Then could you, please, explain what yo
23.05.2018 21:18, Vlad Khorsun via Firebird-devel wrote:
At second, there is no way to upgrade server without breaking established
connection (obviously).
Nobody tell about it. And it change nothing.
Then could you, please, explain what you have on mind when said "remote
server coul
On 23/05/2018 16:18, Vlad Khorsun via Firebird-devel wrote:
> 23.05.2018 15:59, Dimitry Sibiryakov wrote:
>> 23.05.2018 14:40, Mark Rotteveel wrote:
> I think it should unconditionally do a session reset on return to
> the pool if the protocol is v16 or higher (assuming v16 is the
> Fir
23.05.2018 15:59, Dimitry Sibiryakov wrote:
23.05.2018 14:40, Mark Rotteveel wrote:
I think it should unconditionally do a session reset on return to the pool if the protocol is v16 or higher (assuming v16 is the
Firebird 4 protocol version).
This is not truly unconditionally :)
But re
23.05.2018 15:40, Mark Rotteveel wrote:
- New session management statement ALTER SESSION RESET is implemented (see
CORE-5832).
Ticket is not marked as closed for a while as i want to make sure
implementation
is complete. Thus any suggestions, notes, etc are welcome.
As I said in anothe
23.05.2018 14:40, Mark Rotteveel wrote:
I think it should unconditionally do a session reset on return to the pool if the
protocol is v16 or higher (assuming v16 is the Firebird 4 protocol version).
This is not truly unconditionally :)
But relying on protocol version is also not perfect
On 23-5-2018 14:20, Vlad Khorsun via Firebird-devel wrote:
23.05.2018 13:48, Mark Rotteveel wrote:
On 23-5-2018 11:24, Vlad Khorsun via Firebird-devel wrote:
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external
co
23.05.2018 13:51, Vlad Khorsun via Firebird-devel wrote:
I strongly suggest to consider existing DISCONNECT\CONNECT triggers
also. I think, most of the code will be the same in both set of events
therefore it is very questionable if we need another pair of triggers.
I agree, existing trigg
23.05.2018 13:48, Mark Rotteveel wrote:
On 23-5-2018 11:24, Vlad Khorsun via Firebird-devel wrote:
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a ye
On 23/05/2018 08:51, Vlad Khorsun via Firebird-devel wrote:
> 23.05.2018 13:40, Adriano dos Santos Fernandes wrote:
>> On 23/05/2018 06:48, Dimitry Sibiryakov wrote:
>>>
>>> In this case I guess there must be two triggers: BEFORE RESET and
>>> AFTER RESET.
>>
>> I like this more than the other a
23.05.2018 13:40, Adriano dos Santos Fernandes wrote:
On 23/05/2018 06:48, Dimitry Sibiryakov wrote:
In this case I guess there must be two triggers: BEFORE RESET and
AFTER RESET.
I like this more than the other approaches.
I strongly suggest to consider existing DISCONNECT\CONNECT tri
To: firebird-devel@lists.sourceforge.net
Subject: Re: [Firebird-devel] RFC: External Connections Pool
On 23/05/2018 06:48, Dimitry Sibiryakov wrote:
>
> In this case I guess there must be two triggers: BEFORE RESET and
> AFTER RESET.
I like this more than the other approaches.
Also
On 23-5-2018 11:24, Vlad Khorsun via Firebird-devel wrote:
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external
connections.
The feature was initially developed more than a year ago, and works at
production
with g
On 23/05/2018 06:48, Dimitry Sibiryakov wrote:
>
> In this case I guess there must be two triggers: BEFORE RESET and
> AFTER RESET.
I like this more than the other approaches.
Also, a RESET may cause problems to an database application, so an
exception in BEFORE RESET should be possible to abor
23.05.2018 11:58, Dmitry Yemanov wrote:
Wouldn't it make sense to call ON DISCONNECT triggers when the connection is released into
the pool and ON CONNECT triggers when the connection gets reused from the pool?
Do you mean that ALTER SESSION RESET should call them instead of inventing new typ
23.05.2018 12:58, Dmitry Yemanov wrote:
23.05.2018 12:39, Vlad Khorsun wrote:
What useful could such trigger do?
I suppose - the most of the thing that users do on CONNECT (init some context variables, for example) and DISCONNECT (free some
resources).
Wouldn't it make sense to call ON
23.05.2018 12:39, Vlad Khorsun wrote:
What useful could such trigger do?
I suppose - the most of the thing that users do on CONNECT (init some
context variables, for example) and DISCONNECT (free some resources).
Wouldn't it make sense to call ON DISCONNECT triggers when the
connection
23.05.2018 11:39, Vlad Khorsun via Firebird-devel wrote:
What useful could such trigger do?
I suppose - the most of the thing that users do on CONNECT (init some context
variables, for example) and DISCONNECT (free some resources).
In this case I guess there must be two triggers: BEFO
23.05.2018 12:32, Dimitry Sibiryakov wrote:
23.05.2018 11:24, Vlad Khorsun via Firebird-devel wrote:
- At tracker there was proposition to add new database trigger ON RESET which
should
fire when ALTER SESSION RESET is run. Should we implement it ?
What useful could such trigger do?
23.05.2018 11:24, Vlad Khorsun via Firebird-devel wrote:
- At tracker there was proposition to add new database trigger ON RESET which
should
fire when ALTER SESSION RESET is run. Should we implement it ?
What useful could such trigger do?
--
WBR, SD.
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback.
According to discussion in this topic i made
21.05.2018 14:58, Rashid Abzalov wrote:
21.05.2018 14:42, Vlad Khorsun via Firebird-devel wrote:
I don't see how persistent connections in Postgres could be reused by
different user sessions.
No, in Postgres you can reuse only your own connections.
You see - all approaches have its weak
21.05.2018 14:42, Vlad Khorsun via Firebird-devel пишет:
I don't see how persistent connections in Postgres could be reused by
different user sessions.
No, in Postgres you can reuse only your own connections.
Nevertheless, it seems to me that this approach also solves the original
task tha
21.05.2018 14:25, Rashid Abzalov wrote:
Instead of implementing a pool of connections that the system implicitly manages, it might be better to implement named connections
as it is done in Postgres (https://www.postgresql.org/docs/current/static/contrib-dblink-function.html)? Which the user manag
Instead of implementing a pool of connections that the system implicitly
manages, it might be better to implement named connections as it is done
in Postgres
(https://www.postgresql.org/docs/current/static/contrib-dblink-function.html)?
Which the user manages and re-uses as he needs - he knows
21.05.2018 11:47, Dimitry Sibiryakov wrote:
21.05.2018 10:13, Mark Rotteveel wrote:
if pool contain connection to database 1
and user try to connect to also database 1 he can use pool instead normal
connection.
That wouldn't really work
Yes, that wouldn't work. But generally speaking p
21.05.2018 10:13, Mark Rotteveel wrote:
if pool contain connection to database 1
and user try to connect to also database 1 he can use pool instead normal
connection.
That wouldn't really work
Yes, that wouldn't work. But generally speaking pools in Y-valve could be potentially a
little
On 20-5-2018 21:29, liviuslivius wrote:
>>Explain, please. The statement above >>could be understood in many
different >>ways.
>>Regards,
>>Vlad
if pool contain connection to database 1
and user try to connect to also database 1 he can use pool instead
normal connection.
That wouldn't
On 20-5-2018 17:24, Vlad Khorsun via Firebird-devel wrote:
20.05.2018 14:15, Mark Rotteveel wrote:
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
*
>>Explain, please. The statement above >>could be understood in many different
ways.
>>Regards,
>>Vlad
if pool contain connection to database 1and user try to connect to also
database 1 he can use pool instead normal connection.Now i see that you are
talking only when user use execute srat
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.
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.
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 ab
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
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.
T
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 ?
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.
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
-
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
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 sing
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
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
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
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
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
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_PO
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
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 a
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 fi
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) ?
19.05.2018 19:42, Dimitry Sibiryakov wrote:
"SET ROLE" statement issued in EDS is not handled in any way, right?
Yes
Regards,
Vlad
--
Check out the vibrant tech community on one of the world's most
engaging tech
"SET ROLE" statement issued in EDS is not handled in any way, right?
--
WBR, SD.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebir
19.05.2018 19:38, Dimitry Sibiryakov wrote:
BTW, what behavior is expected from GTT ON COMMIT PRESERVE in pooled
connection?
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 s
19.05.2018 18:25, Vlad Khorsun via Firebird-devel wrote:
We have single engine instance (local) which handle connections to two
databases each
of them have own security database. Both security databases contains user John.
Both
John's established own connection to the different databases and
19.05.2018 18:52, Dimitry Sibiryakov wrote:
>>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
to
19.05.2018 17:11, Vlad Khorsun via Firebird-devel wrote:
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
19.05.2018 13:08, Mark Rotteveel wrote:
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 immed
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.externa
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
On 18-5-2018 18:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external
connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback.
Some bugs was fixed since then, so it sh
18.05.2018 21:30, Vlad Khorsun via Firebird-devel wrote:
So far there is no such decision (to consider engine13.conf as a "right
place" and
that firebird.conf is legacy). And I see no reason to discuss it in this thread.
README.plugins clearly state this:
when plugin PlugName is needed
18.05.2018 22:15, Dimitry Sibiryakov wrote:
18.05.2018 20:49, Vlad Khorsun via Firebird-devel wrote:
Whole EDS feature is implemented as part of engine.
Shouldn't new configuration parameters to be in the right place for plugin's parameters: engine13.conf instead of legacy pile
firebird
18.05.2018 20:49, Vlad Khorsun via Firebird-devel wrote:
Whole EDS feature is implemented as part of engine.
Shouldn't new configuration parameters to be in the right place for plugin's
parameters: engine13.conf instead of legacy pile firebird.conf?..
--
WBR, SD.
---
18.05.2018 21:19, Dimitry Sibiryakov wrote:
18.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:
Please, read and comment:
Is the connection pool an "engine thing" or it is at server/Y-valve level?
Whole EDS feature is implemented as part of engine.
Isn't password redundant
18.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:
Please, read and comment:
Is the connection pool an "engine thing" or it is at server/Y-valve level?
Isn't password redundant in search?
--
WBR, SD.
-
All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback.
Some bugs was fixed since then, so it should be stable enough and definitely
good for beta release of v4.
91 matches
Mail list logo
