Subject Re: [IBO] Transaction management and AutoCommit
Author Robert Martin
Hi Helen

Thanks for your great response :)

On 27/03/2014 10:50 a.m., Helen Borrie wrote:
> Not really. Next Transaction is not interesting from the POV of transaction management in your application. It hasn't happened yet!
>
> 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.
Ok, thanks for clearing that up. Am I correct in saying the 'Oldest
Transaction' = OIT and 'Oldest Active' = OAT?

>
> 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

I have a large application that used to be based on DBase. During
conversion to FB we used the AutoCommit functionality to avoid having to
re code large parts of the application. I was doing some stability
tests by simply processing a POS (Point of Sale) process repeatedly
(1million times). I noticed that the time to process each POS
transaction slowly increased. I did a GStat and noticed the big gap
between 'Next Transaction' and the Oldest transaction entries and
thought this could be the culprit!

I have just checked on the machine and POS transactions have slowed to
taking 42s each !!!!! after about 500,000. GStat gives me the
following....


Database header page information:
Flags 0
Checksum 12345
Generation 1554500
Page size 8192
ODS version 11.2
Oldest transaction 632200
Oldest active 632201
Oldest snapshot 632201
Next transaction 1489694
Bumped transaction 1
Sequence number 0
Next attachment ID 64798
Implementation ID 26
Shadow count 0
Page buffers 20000
Next header page 0
Database dialect 3
Creation date Mar 13, 2014 9:23:30
Attributes force write

Variable header data:
Sweep interval: 20000
*END*

If I understand what you are saying, this is OK because the gap between
the OIT and the OAT is minimal? However it does appear to be Stuck in
that the OIT and OAT are not advancing?



Thanks
Rob