On 05/05/2017 14:01, Vlad Khorsun wrote: > > It doesn't forces (nor expresses) new transaction isolation level to be > SNAPSHOT.
Yes, I forgot to inform it in comment for now. > Probably, it would be more natural to extend "snap_shot" rule in parser: > > iso_mode > : snap_shot > | READ UNCOMMITTED version_mode > | READ COMMITTED version_mode > ; > > %type <uintVal> snap_shot > snap_shot > : SNAPSHOT > | SNAPSHOT TABLE > | SNAPSHOT TABLE STABILITY > + | SNAPSHOT SHARING FROM <N> I like it. > Also, transaction_options() should verify\enforce isc_tpb_concurrency > isolation > level for a new transaction. Yes. > I don't understand for what purpose tra_oldest_snapshot was added. In my understand, it's a property that new transaction should copy from the base transaction. Isn't it? Should I let the original code assign it even for new transactions that's sharing a snapshot? But please read answear bellow, may be important for it. > Also it is not clear why "base_number" variable is introduced in > transaction_start() > and why it replaces "number" in many places. When first normal (not with sharing snapshot option) transaction is started, it must record others transaction snapshot until its own *number*. When second (with sharing snapshot option) transaction is started, *number* has its new number too, but the snapshot vector must be record only to the *base_number*, i.e., its snapshot vector should be identical to the first transaction. Adriano ------------------------------------------------------------------------------ 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
