Subject Re: [Firebird-Architect] Question on classic
Author Jim Starkey
Dmitry Yemanov wrote:

>"Ann W. Harrison" <aharrison@...> wrote:
>>He stores a record in thread1 and commits it, then wakes
>>thread2. Thread2 doesn't immediately see the new record,
>>but does eventually. In thinking it over, I'm not at all
>>sure how or when the state of newly committed transactions
>>is conveyed to separate classic processes. Do you know?
>VIO asks TRA_snapshot_state(). For read-committed, TRA_snapshot_state()
>relies on the transaction cache. TPC_snapshot_state() returns its cached
>value only if it's committed or dead. For supposedly active transaction it
>tries to get a lock of the transaction ID. If failed - return active. If
>succeeded, refetch the TIP.
>Looks correct and reliable for classic at the first glance.
Unfortunately, the transaction cache isn't reliable for this purpose,
though ironically, it is for normal transactions.

Probably the best way to fix read committed transaction is for
TRA_snapshot_state to refer to the tip rather than the cache. It's a
page fetch but a page fetch that's a guaranteed cache hit unless the TIP
been changed by another process, which is exactly what is required. It
does mean that read committed "transactions" induce a higher system cost
than reliable transactions, but I rather believe this sends the right