| Subject | Re: [IBO] Transaction management and AutoCommit |
|---|---|
| Author | Helen Borrie |
| Post date | 2014-03-26T21:50:55Z |
At 09:39 a.m. 27/03/2014, Robert Martin wrote:
Older transactions remain "interesting" as long as there are records OR INDICES that need to be marked. What's of concern is big gaps between Oldest (OIT) and Oldest Active (OAT). Actually, Vlad Khorsun says the gap of concern is the one between OIT and Oldest Snapshot. The latter represents the TID that was the OAT when the most recent garbage collection was attempted.
You're using Superclassic so you don't have any background threads doing GC as you do in Superserver. GC happens only when records that are interesting to any old transactions are touched by a select. What happens there is that the uninteresting records are marked. Next time around, if yea-transaction has no interesting records, the OIT is kicked forward to the next transaction that was interesting last time. Don't confuse the in-process GC with sweeping. With sweeping, the marking and clearance happen as a sequence of events within the sweep process itself.
Your tests aren't very useful, btw. An insert causes one and only one record version to be created. As far as the global database knows, your inserted records don't exist until they are committed. Unless you are using CommitRetaining, the newly inserted records will not get interesting until another transaction modifies or deletes them. However, the indices involved ARE interesting and remain so until there are no caches left that need the old indexes kept warm. (Remember, each SC connection has its own cache.) When the coast is clear (the last attachment is gone and thus, its cache) the engine will try to clean up the indices.
Your gstat figures don't suggest a problem with transaction management, at least in terms of a stuck OIT. What's the problem you are trying to troubleshoot?
Helen
>HiNot really. Next Transaction is not interesting from the POV of transaction management in your application. It hasn't happened yet!
>
>Further to my last email. I have just run the code again with these
>results
>
>
> Oldest transaction 441772
> Oldest active 441773
> Oldest snapshot 441773
> Next transaction 456774
>
>
>I note that in my first email the 'Oldest transaction' had caught up
>with 'Next transaction'. It hasn't in the above and in most of my tests
>the results are as above not below. Weird!
Older transactions remain "interesting" as long as there are records OR INDICES that need to be marked. What's of concern is big gaps between Oldest (OIT) and Oldest Active (OAT). Actually, Vlad Khorsun says the gap of concern is the one between OIT and Oldest Snapshot. The latter represents the TID that was the OAT when the most recent garbage collection was attempted.
You're using Superclassic so you don't have any background threads doing GC as you do in Superserver. GC happens only when records that are interesting to any old transactions are touched by a select. What happens there is that the uninteresting records are marked. Next time around, if yea-transaction has no interesting records, the OIT is kicked forward to the next transaction that was interesting last time. Don't confuse the in-process GC with sweeping. With sweeping, the marking and clearance happen as a sequence of events within the sweep process itself.
Your tests aren't very useful, btw. An insert causes one and only one record version to be created. As far as the global database knows, your inserted records don't exist until they are committed. Unless you are using CommitRetaining, the newly inserted records will not get interesting until another transaction modifies or deletes them. However, the indices involved ARE interesting and remain so until there are no caches left that need the old indexes kept warm. (Remember, each SC connection has its own cache.) When the coast is clear (the last attachment is gone and thus, its cache) the engine will try to clean up the indices.
Your gstat figures don't suggest a problem with transaction management, at least in terms of a stuck OIT. What's the problem you are trying to troubleshoot?
Helen