24.03.2020 15:34, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-24 12:53, Vlad Khorsun wrote:
24.03.2020 9:54, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-23 22:18, Dimitry Sibiryakov wrote:
Hello, All.
Is it bug or intended?
Bug.
Not really. I see no checks in engine against duplication of any DPB tag, it
is not
described in IB docs, so it is not forbidden, at least formally. But I agree,
it would
be better to remove old value before insert new one. Actually, it makes no harm
as
engine uses value from last found tag.
insertSomething() does not guarantee to add tag in the end of a buffer (it's
insert, not append)
I.e. only if previous actions do set current position to eof new tag will go to the end. Relying on it is not very good idea (though
may work).
In this case it works. As I already said that this is not final code I see no
reason to continue argue here.
Added first in Provider::generateDPB(), next in (any-)Connection::attach().
Vlad, I'm unsure - what place is correct one?
Second was added with connections pool implementation in master. This part
requires
some completion. isc_dpb_ext_call_depth was introduced by me at initial
implementation
of EDS to detect and prevent too deep recursion within EDS.
isc_dpb_ext_call_depth
passed at attach() with incremented call depth counter of local attachment.
Now, with
connections pooling, I need a way to set call depth counter of re-used
attachment.
So far we have no such way and I open for suggestions. When this will be
implemented,
isc_dpb_ext_call_depth could be removed from Provider::generateDPB(). Currently
it
works as a some protection from bad scenarios with recursive calls of EDS.
It should help from infinite recursion - pools on involved servers should overflow at some step, and tag will work as before. Though
certainly it's not precise result.
Not sure I got you here - why it is not precise ?
May be better solution is related with attachment's reset?
Pooled connection is reset when released, not when reused.
Thus - no, connection reset can not help.
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
