Project

General

Profile

Bug #44

Error during transaction.commit() causes infinite recursion and looping

Added by ronald - over 16 years ago. Updated about 16 years ago.

Status:
Closed
Priority:
High
Assignee:
Andrae Muys -
Category:
Mulgara
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed

Description

This is svn head (rev <a href="http://mulgara.org/trac/changeset/189">189</a>), i.e. with the new transaction code.
<br/>

<br/>
Here's a small snippet of the stack when the error is triggered:
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:222)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.mulgara.resolver.MulgaraTransaction.terminateTransaction(MulgaraTransaction.java:330)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.mulgara.resolver.MulgaraTransaction.deactivate(MulgaraTransaction.java:154)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.mulgara.resolver.MulgaraTransaction.execute(MulgaraTransaction.java:207)
<br/>

<br/>
If commit() throws an exception, implicitRollback() will be invoked at
<br/>
line 333, which in turn call checkActivated() on line 262, which in
<br/>
turn calls implicitRollback() on line 442 because inuse is 0 (from
<br/>
deactivate()).
<br/>

<br/>
At this point things go horribly wrong...
<br/>

<br/>
An easy way to trigger this is run out of disk space where the db
<br/>
resides (e.g. on linux create a fs on a small file and mount using the
<br/>
loop device: 'dd if=/dev/zero of=/tmp/mdb bs=4096 count=1000',
<br/>
'mke2fs /tmp/mdb', 'mount -o loop /tmp/mdb /mnt/disk').
<br/>

<br/>
#1

Updated by Andrae Muys - over 16 years ago 

I'll address this next week, for now just comment out the call to checkActivated() - it shouldn't ever fail - for those times it probably manages to anyway, I'll figure what to do there next week.
#2

Updated by ronald - over 16 years ago 

Just to confirm: we're talking about commenting out line 263 (as of rev <a href="http://mulgara.org/trac/changeset/192">192</a>), right?
#3

Updated by Andrae Muys - over 16 years ago 

Yes.
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;try {
<br/>
//      checkActivated();
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rollback = IMPLICIT_ROLLBACK;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rollbackCause = cause;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;failTransaction();
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return new [[MulgaraTransactionException]](&quot;Transaction in Rollback&quot;, cause);
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;} catch (Throwable th) {
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;abortTransaction(&quot;Failed to rollback normally&quot;, th);
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw new [[MulgaraTransactionException]](&quot;Abort failed to throw exception&quot;, th);
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}
<br/>

<br/>
The check is there as a defensive measure as execution should only reach that point if the transaction is activated.  Removing it will ensure rollback get's set, which will short-circuit any future call to implicitRollback().
<br/>

<br/>
I'll take a closer look and determine what the permanent fix should be next week.
#4

Updated by ronald - over 16 years ago 

I had to make one small additional modification: line 357 needs to
<br/>
be protect with an if:
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try {
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (manager != null)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;manager.transactionComplete(this);
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} finally {
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;manager = null;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;inuse = 0;
<br/>

<br/>
This is because on line 335 terminateTransaction() is called recursively,
<br/>
and the third finally clause sets manager to null, so after the
<br/>
terminateTransaction() returns the first time you get a NPE otherwise.
<br/>

<br/>
This is just an FYI in case somebody else needs this fix in the mean
<br/>
time. With these two changes things seem to run well.
<br/>

<br/>
#5

Updated by Andrae Muys - about 16 years ago 

Fixed in revision <a href="http://mulgara.org/trac/changeset/207">207</a>

Also available in: Atom PDF