Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
We have a GT.M system that is performing about 20,000 update Transactions per day. We are seeing the following error about once every 2 or 3 days.
%GTM-E-TRESTNOT, Cannot TRESTART, transaction is not restartable,%GTM-E-TRESTLOC, Transaction start: wg+8^a14, Transaction failure: eposDepa+6^ems10
The update code within the scope of the transaction references a number of globals but careful analysis has not yet uncovered any possibility of a conflicting update by another process on the system.
I'm wondering if there is any possibility that there might be a bug in this version of GT.M (V4.4-003 Linux x86) that might trigger a spurious restart?
Also, is there any way of identifying (from error log info etc) what the cause of the restart would be?
It is feasible to make the transaction restartable but we are concerned that it might mask any underlying cause and we'd rather get to the bottom of the problem than just avoid it.
Any help or ideas would be much appreciated.
Owing to the heuristics that GT.M uses to manage global buffers, it is quite possible, with a low probability (in your case, perhaps one in 40,000 or one in 60,000), for a process to step on its own toes, even if it is the only process on the system, and be forced to restart a transaction.
All (useful) transactions on GT.M need to be flagged as restartable. That is a consequence of GT.M's optimistic concurrency control implementation of transactions processing.
Thank you, that is exactly the answer I was hoping for. We'll go ahead and make it restartable without any further worry.
Thank you, as well, for a very quick response.