Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 117883 - DB transactions get left open when TransactionContext#beforeCommit even throws an error.
DB transactions get left open when TransactionContext#beforeCommit even throw...
Product: Red Hat Web Application Framework
Classification: Retired
Component: persistence (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Archit Shah
Jon Orris
Depends On:
Blocks: 113496
  Show dependency treegraph
Reported: 2004-03-09 11:59 EST by Daniel Berrange
Modified: 2007-04-18 13:04 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-17 15:41:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2004-03-09 11:59:27 EST
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 16:45:47 EST
committed a tentavie fix at 41194
Comment 2 Daniel Berrange 2004-03-11 13:20:58 EST
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 15:41:18 EST
Added test at 41464

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