Bugzilla – Full Text Bug Listing
| Summary: | UnitOfWorkImpl.commitTransactionAfterWriteChanges method doesn't handle rollback correctly | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Steve Willcox <swillcox> |
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | burke.webster, christopher.delahunt, swillcox, tom.ware |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines Note: The number of votes indicates this bug has a good chance of being bumped up. (although we will likely have some discussions amoung the committers about how to deal with bugs with lots of votes that appear to come from the same source.) baa. Humbug. :) *** This bug has been marked as a duplicate of bug 325002 *** The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |
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.