Description Steve Willcox 2010-09-03 13:04:41 EDT

Build Identifier: 2.1.0

If you get a database exception in in the commitTransaction() call in this method, rollback gets called twice in the following code:
            } catch (RuntimeException exception) {
                if (getDatasourceLogin().shouldSynchronizeObjectLevelReadWriteDatabase() && (getMergeManager() != null)) {
                    // 272022: If the current thread and the active thread on the mutex do not match - switch them
                    verifyMutexThreadIntegrityBeforeRelease();
                    // exception occurred during the commit.
                    this.parent.getIdentityMapAccessorInstance().getWriteLockManager().releaseAllAcquiredLocks(getMergeManager());
                    setMergeManager(null);
                }
                rollbackTransaction();
                release();
                handleException(exception);
            }

It gets called by the rollbackTransaction() call and in the release() which results in an exception being thrown in ConcurrencyManger.release() method since the depth is now zero (caused by the second rollback call).

As a result the original exception is lost and you can't tell why the transaction failed.

Reproducible: Always

Steps to Reproduce:
1.Create a spring transactional method with a UnitOfWork.writeChanges() method call in it.
2.Make sure you have changes in the TX that will cause a SQLException (like a constraint violation).
3.Run the test and notice you don't get the SQLException but a ConcurrencyManagerException.