Bugzilla – Full Text Bug Listing
| Summary: | JPA OptimisticLockExceptions get logged multiple times | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Chris Delahunt <christopher.delahunt> |
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | michael.f.obrien, tom.ware |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 320643 | ||
| Bug Blocks: | |||
>See recent patch from bug# 320643 for reference on the native to spec rethrow change for the OLE >While not directly related to the issue RWUOW.commitToDatabase() - the two functions catch and rethrow native->spec OLE - therefore both should be changed together. https://bugs.eclipse.org/bugs/attachment.cgi?id=189210&action=diff#foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/RepeatableWriteUnitOfWork.java_sec2 The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |
When using JPA with Java EE persistence exceptions can get logged multiple times. Example is when merging an Entity that would cause an OptimisticLockException when the transaction commits. This results in a org.eclipse.persistence.exceptions.OptimisticLockException that is logged somewhere in the UnitOfWorkImpl.commitToDatabase call correctly: "<Mar 17, 2011 5:25:13 AM EDT> <Warning> <EclipseLink> <BEA-2005000> <2011-03-17 05:25:13.376--UnitOfWork(837581112)--Exception [EclipseLink-5006] (Eclipse Persistence Services - 2.1.2.v20101206-r8635): org.eclipse.persistence.exceptions.OptimisticLockException Exception Description: The object [Entity@31ec79e7] cannot be updated because it has changed or been deleted since it was last read. Class> Entity Primary Key> 125508> " The RepeatableWriteUnitOfWork.commitToDatabase method catches the exception and wraps it in a javax.persistence.OptimisticLockException to be spec complient, which leads to it getting logged 2 additional times since it is no longer an EclipseLinkException and the hasBeenLogged flag is not accessible. The stack for the javax persistence exception is: org.eclipse.persistence.exceptions.OptimisticLockException Exception Description: The object [Entity@3212b3f7] cannot be updated because it has changed or been deleted since it was last read. Class> Entity Primary Key> 108395 at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:612) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1527) at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3181) at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:332) at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68) at weblogic.transaction.internal.ServerSCInfo.doBeforeCompletion(ServerSCInfo.java:1239) This javax exception will get logged in UnitofWork.commitToDatabaseWithChangeSet and beforeCompletion. EclipseLink either needs to wrap the exception later on in the stack so the hasBeenLogged is accessible, or to get the wrapped exeception in AbstractSession.handleException where the exception is logged.