Bug 117883

Summary: DB transactions get left open when TransactionContext#beforeCommit even throws an error.
Product: [Retired] Red Hat Web Application Framework Reporter: Daniel Berrange <berrange>
Component: persistenceAssignee: Archit Shah <archit.shah>
Status: CLOSED RAWHIDE QA Contact: Jon Orris <jorris>
Severity: high Docs Contact:
Priority: medium    
Version: nightly   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-17 20:41:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 113496    

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