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 could be done in the single stored procedure call
(which could call another SP and so on).
Then run same remote statement again at another local transaction.
With pre-v4 remote server there could be *new* connection with *empty*
context variable
or reused (and *not reset*) connection with *some value* in context variable.
I see.
Let me summarize in simple words:
1) Local v3, remote v3: always new connection with empty variables.
2) Local v3, remote v4: always new connection with empty variables.
3) Local v4, remote v3: behavior may vary:
3.1) Implemented (1): always new connection with empty variables.
+ pool is effectively disabled and give no benefits
+ overhead executing statement that can't be handled by remote
I.e. all works a bit slower than before v4.
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 in
simple case. Pool works. No overhead. User could prevent unwanted contex
reuse but it is not always easy to do.
All works much faster than before v4.
4) Local v4, remote v4: some connection with empty variables.
Is this table right?
Now it is more complete
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
