On 24/02/2019 08:23, Vlad Khorsun wrote:
> TPB: isc_tpb_snapshot_commit_number, <commit number length>
<commit number>
isc_tpb_snapshot_number <len> <value>
Regards,
Vlad
PS we also must add isc_info_tra_snapshot_number and, probably,
context variable.
Don't we already have context SNAPSHOT_CN? It already has the same
meaning of the new feature, so therefore what context you would want
to add?
SNAPSHOT_CN returns snapshot number of current request if
transaction is read-committed read
consistency (RCRC). But... after more thinking i consider it is ok to
use it for snapshot cloning.
Additional variable returning NULL for RCRC transactions will add more
confusing. From the other
side - there is no problem to clone any kind of existing snapshot.
Users must be warned that snapshot
transaction which cloned request-level snapshot of another RCRC
transaction will see same data at
base request and subsequent requests in the base RCR transaction could
see another data.
Yes, and that is already possible as an implementation side effect. It
should be extremely discouraged, except for cases like long running
request detected via monitoring that one wants to debug in another
connection.
I also suggest that new isc_info_tra_snapshot_number returns the
same data as SNAPSHOT_CN variable.
Yes, no problem. But for RC it will be NULL as there is no request.
And then SNAPSHOT_CN means "SNAPSHOT COMMIT NUMBER", it's the reason
for the syntax that I offered.
We can change it, if needed. Note, I introduced two variables:
GLOBAL_CN and SNAPSHOT_CN and its
names looks logical and consistent to me (at least at that time). I
see no problem to change names
to something better.
Yes, the names must match as SNAPSHOT_CN means same thing as the clause
passed to SET TRANSACTION.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
