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
ng tech
sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web
interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
__ Information from ESET Mail Security, version of virus signature
database 17431 (20180523) __
The message was checke
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 matches
Mail list logo
