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).
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.
May be better solution is related with attachment's reset?
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
