Re: Broken transaction

On Wed, 1 Jul 1998, Nigel Gall wrote: > Platform: Digital UNIX 3.0b > OnLine : 5.05.UC1 > 4GL : 4.13.UD1 Pcode Version 8 > > Is there any condition, aside from an error in programming, which would > cause half (or piece) of a transaction to occur and not the other, even > when both (or all) commands are within the begin work/commit work block? > > Around the time this happens, I get the following messages in the error log > for the user: > > SQL statement error number -271. > Could not insert new row into the table. > SYSTEM error number -154. > ISAM error: Lock Timeout Expired> > According to the documentation, if the deadlock condition has exceeded > the time specified by the tbconfig parameter DEADLOCK_TIMEOUT, then it is > supposed to rollback the transaction and try again after a delay. What > I'm experiencing is that the error is registered, and pieces of my > transaction are not rolled back. What's happening is that the statement fails and is completely cancelled, so the database is in the same state after the failure as it was before the insert failed. Also, the lock time out may be different from the DEADLOCK_TIMEOUT to which you refer; that would require a distributed transaction between several different OnLine servers, and you make no mention of remote servers. -154 ISAM error: Lock Timeout Expired. This network operation has been suspended, awaiting a response from another database server, for the maximum duration allowed. The INFORMIX-OnLine Dynamic Server assumes that a distributed deadlock exists and that this user request is awaiting a resource that was locked by a user in a different system, which is awaiting a resource that this user owns. Roll back the current transaction, and retry it after a delay. If this error occurs frequently, ask the OnLine administrator to adjust the length of the deadlock time-out interval. This code is also returned when an explicit wait time limit expires; that is, if you have SET LOCK MODE TO WAIT 3, and your request is queued for more than 3 seconds for a lock, the operation ends with this ISAM error code. Your transaction is not unilaterally rolled back because you may have a method for working around such problems. If your application needs the transaction cancelled after this error, do it explicitly, but remember that your code needs to know this has happened. If you were using a MODE ANSI database, you could do the rollback, but you'd also implicitly start a new transaction, so unless your code noted the error, it would continue on the assumption that the first half of the transaction was complete, whereas it has actually been rolled back. That would be nasty in the extreme. If you feel the documentation is misleading, tell the Documentation Team at Informix that it is misleading -- the email alias listed in the manuals is doc@informix.com. You normally get a good response from them; that is, it is fairly timely and tells you that the issue has been saved and noted for review during the next round of revisions of the manuals. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix -- see http://www.perl.com/CPAN