20.02.2021 16:56, Mark Rotteveel wrote:
On 20-02-2021 15:39, Vlad Khorsun wrote:
20.02.2021 14:27, Mark Rotteveel wrote:
What does SET TRANSACTION option RESTART REQUESTS do?
In the code (tra.cpp, restart_requests(...), I only see the comment:
"""
Restart all requests in the current attachment to utilize the passed
transaction.
"""
This doesn't really help me understand what this does,
Exactly as written - restart all (prepared) requests in the current
attachment.
It doesn't send input params, btw.
On second look I need to correct myself - not *all* prepared requests are
restarted,
but only active requests (of the same attachment). And it makes the feature
even more
strange: imagine transaction that fetches from cursor and after starting of
another
transaction with RESTART REQUESTS option its cursor being reset, started again
and
assigned to the new transaction. I even don't know how client app will react.
This is
why I call it "half-done".
Also, note: if new transaction is the only in the attachment, its RESTART
REQUESTS
option is NOOP.
Ok, but what does 'restarting' requests do? What are 'requests' in this
context, and what are the effects of restarting them?
Does it mean that any prepared statement is re-executed? Or are active select
statements re-executed and their cursors retained?
Hope, it is answered above.
and how it's useful or supposed to be used (if ever).
I can't explain what idea was behind this option. Probably this is the reason
of not documenting this (half-done?) feature...
That sounds scary to be honest.
Why ? This feature is not known for users, you are the first who publicly ask
about
it in last 20 years, I believe. BTW, this feature is legacy from IB6 code, it
is not
FB invention. I thought it is obvious ;)
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
