Bug 117883 - DB transactions get left open when TransactionContext#beforeCommit even throws an error.
Summary: DB transactions get left open when TransactionContext#beforeCommit even throw...
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: persistence
Version: nightly
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Archit Shah
QA Contact: Jon Orris
Depends On:
Blocks: 113496
TreeView+ depends on / blocked
Reported: 2004-03-09 16:59 UTC by Daniel Berrange
Modified: 2007-04-18 17:04 UTC (History)
0 users

Clone Of:
Last Closed: 2004-03-17 20:41:18 UTC

Attachments (Terms of Use)

Description Daniel Berrange 2004-03-09 16:59:27 UTC
Description of problem:
The dispatcher code makes use of DatabaseTransaction class for
committing / aborting transactions. This wraps calls to
begin/commit/abort in TrnsactionContext so with checks to the inTxn()
method. The inTxn() method is modelled with the m_inTxn member variable.

There is a problem in the way this variable is updated from the
abort/commit events. This code is from the 'commitTxn' method:

        boolean success = false;
        try {
            m_ossn.invalidateDataObjects(true, false);
            success = true;
            m_inTxn = false;
        } finally {
            m_inTxn = false;
            if (!success) { m_ossn.invalidateDataObjects(false, true); }

The import thing to notice is the 'm_inTxn = false' line in the
'finally' block. Consider what happens when fireBeforeCommit throws an
exception. The 'm_ssn.commit()' method will never be called, and yet
'm_inTxn' will be toggled to false. The dispatcher later catches the
Exception and calls 'DatabaseTransaction#rollback' - but because
'TransactionContext#inTxn()' is now returning false, the
DatabaseTransaction object will never call rollback on the underlying
TransactionContext object.

We now have an open database transaction lieing around holding open
locks on a great many tables. This is causes Camden's Production
servers to lock up completely about 1-2 times a week.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Do something that causes beforeCOmmit event to throw an exception 
2. Examine locks held in thedatabase & SQL being operated  by each
Actual results:
Many sessions are waiting on locks held by an idle connection with an
open DB transaction

Expected results:

Additional info:

Comment 1 Archit Shah 2004-03-09 21:45:47 UTC
committed a tentavie fix at 41194

Comment 2 Daniel Berrange 2004-03-11 18:20:58 UTC
Looking at the code for 5.2, this needs to be backported too, and
likely for 6.0 as well.

Comment 3 Jon Orris 2004-03-17 20:41:18 UTC
Added test at 41464

Note You need to log in before you can comment on or make changes to this bug.