Hi,
I have an issue whose cause lies somewhere between OpenJPA and Aries. Posting it here first,
please redirect me if it's the wrong place.
We use Open JPA in Karaf 3.0.2 (detailed bundle versions below). We have an DAO object, instantiated
by Blueprint with a jpa:context and a tx:transaction element. It gets the EntityManager from
Aries JPA and has a mandatory transaction on each method call.
<bean id="masterDataDao" depends-on="dataSource" class="some.package.MasterDataDaoImpl">
<jpa:context unitname="masterDataDb" property="entityManager"/>
<tx:transaction method="create,delete,find*,get*,update" value="Mandatory"/>
</bean>
That DAO object has CRUD methods for an entity class that uses optimistic locking. It has
a long version field annotated with @Version.
Our problem appears when we get the optimistic lock error. We would expect our MasterDataDao.update
method to throw a TransactionRollbackException with an OptimisticLockException as its cause.
Instead it throws a TransactionRollbackException with a SetRollbackOnlyException as its cause
(TransactionImpl.java:272).
The question is why?
I tried debugging the issue. I put a breakpoint at org.apache.geronimo.transaction.manager.TransactionImpl.markRollbackCause(java.lang.Throwable)
line: 539. AFAIU the problem is that that method is called *TWICE* when a transaction is processed.
The first time it is called with the "wrong" exception - SetRollbackOnlyException, the second
time it's called with the correct OptimisticLockException, but the correct exception isn't
recorded in the TransactionImpl object because the markRollbackCause method looks like this:
private void markRollbackCause(Throwable e) {
if (markRollbackCause == null) {
markRollbackCause = e;
}
}
So the first time the field is set to a "wrong" value and when the correct value comes it's
lost.
I took stacktraces of both invocations. AFAIU the crucial bit is the TransactionImpl.beforeCompletion(java.util.List)
method. It first calls synch.beforeCompletion() and then markRollbackCause. The problem is
that synch.beforeCompletion gets to markRollbackCause first. Why? Is it known? Is it a bug?
Is it some misconfiguration? Is it supposed to be fixed in Karaf 3.0.3 and its openjpa feature?
Why does PersistenceExceptions$2.translate(java.lang.RuntimeException) call EntityManager.setRollbackOnly()?
The first markRollbackCause invocation (from the RuntimeExceptionTranslator that calls EntityManager.setRollbackOnly):
Thread [qtp1832761053-45] (Suspended (breakpoint at line 539 in org.apache.geronimo.transaction.manager.TransactionImpl))
owns: org.apache.geronimo.transaction.manager.TransactionImpl (id=152)
owns: org.eclipse.rap.rwt.internal.util.SerializableLock (id=153)
org.apache.geronimo.transaction.manager.TransactionImpl.markRollbackCause(java.lang.Throwable)
line: 539
org.apache.geronimo.transaction.manager.TransactionImpl.setRollbackOnly(java.lang.Throwable)
line: 134
org.apache.geronimo.transaction.manager.TransactionImpl.setRollbackOnly() line: 126
org.apache.openjpa.ee.JNDIManagedRuntime.setRollbackOnly(java.lang.Throwable) line: 71
org.apache.openjpa.ee.AutomaticManagedRuntime.setRollbackOnly(java.lang.Throwable) line:
274
org.apache.openjpa.kernel.BrokerImpl.setRollbackOnlyInternal(java.lang.Throwable) line:
1674
org.apache.openjpa.kernel.BrokerImpl.setRollbackOnly(java.lang.Throwable) line: 1654
org.apache.openjpa.kernel.DelegatingBroker.setRollbackOnly(java.lang.Throwable) line: 981
org.apache.openjpa.persistence.EntityManagerImpl.setRollbackOnly(java.lang.Throwable) line:
631
org.apache.openjpa.persistence.PersistenceExceptions$2.translate(java.lang.RuntimeException)
line: 76
org.apache.openjpa.kernel.BrokerImpl.translateManagedCompletionException(java.lang.RuntimeException)
line: 2093
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion() line: 2027
org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(java.util.List)
line: 527
org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion() line: 511
org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare() line: 413
org.apache.geronimo.transaction.manager.TransactionImpl.commit() line: 262
org.apache.aries.transaction.internal.AriesTransactionManagerImpl(org.apache.geronimo.transaction.manager.TransactionManagerImpl).commit()
line: 252
Proxy94d42c5b_f0da_4685_aa62_e265cec6c45a.commit() line: not available
org.apache.aries.transaction.TransactionAttribute$4.finish(javax.transaction.TransactionManager,
org.apache.aries.transaction.TransactionToken) line: 94
org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(org.osgi.service.blueprint.reflect.ComponentMetadata,
java.lang.reflect.Method, java.lang.Object, java.lang.Object) line: 85
org.apache.aries.blueprint.proxy.Collaborator.postInvoke(java.lang.Object, java.lang.Object,
java.lang.reflect.Method, java.lang.Object) line: 105
Proxy8b595ed5_edc7_4490_8e6d_48b3560da384.update(somepackage.MasterData) line: not available
The second one (directly from TransactionImpl):
Thread [qtp1832761053-45] (Suspended (breakpoint at line 539 in org.apache.geronimo.transaction.manager.TransactionImpl))
owns: org.apache.geronimo.transaction.manager.TransactionImpl (id=152)
owns: org.eclipse.rap.rwt.internal.util.SerializableLock (id=153)
org.apache.geronimo.transaction.manager.TransactionImpl.markRollbackCause(java.lang.Throwable)
line: 539
org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(java.util.List)
line: 531
org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion() line: 511
org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare() line: 413
org.apache.geronimo.transaction.manager.TransactionImpl.commit() line: 262
org.apache.aries.transaction.internal.AriesTransactionManagerImpl(org.apache.geronimo.transaction.manager.TransactionManagerImpl).commit()
line: 252
Proxy94d42c5b_f0da_4685_aa62_e265cec6c45a.commit() line: not available
org.apache.aries.transaction.TransactionAttribute$4.finish(javax.transaction.TransactionManager,
org.apache.aries.transaction.TransactionToken) line: 94
org.apache.aries.transaction.TxInterceptorImpl.postCallWithReturn(org.osgi.service.blueprint.reflect.ComponentMetadata,
java.lang.reflect.Method, java.lang.Object, java.lang.Object) line: 85
org.apache.aries.blueprint.proxy.Collaborator.postInvoke(java.lang.Object, java.lang.Object,
java.lang.reflect.Method, java.lang.Object) line: 105
Proxy8b595ed5_edc7_4490_8e6d_48b3560da384.update(somepackage.MasterData) line: not available
All kinds of comments welcome.
--
Antoni Myłka
Software Engineer
Quantinum AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 388 20 40
http://www.quantinum.com - Experience the Power of Data
P.S. Versions of the relevant bundles
9 | Active | 20 | 1.1.0 | Apache Aries Util
10 | Active | 20 | 1.0.1 | Apache Aries Proxy API
11 | Active | 20 | 1.0.3 | Apache Aries Proxy Service
12 | Active | 20 | 1.0.1 | Apache Aries Blueprint API
13 | Active | 20 | 1.0.5 | Apache Aries Blueprint CM
14 | Resolved | 20 | 1.0.0 | Apache Aries Blueprint Core Compatiblity Fragment
Bundle, Hosts: 15
15 | Active | 20 | 1.4.1 | Apache Aries Blueprint Core, Fragments: 14
71 | Active | 50 | 0 | wrap_mvn_postgresql_postgresql_9.1-901.jdbc4
76 | Active | 30 | 1.1.1 | geronimo-jta_1.1_spec
77 | Active | 30 | 1.0.1 | Annotation 1.1
96 | Active | 30 | 1.0.0 | Aries JPA Container API
97 | Active | 30 | 1.0.1 | Aries JPA Container blueprint integration for
Aries blueprint
98 | Active | 30 | 1.0.0 | Aries JPA Container
99 | Active | 30 | 1.0.1 | Aries JPA Container Managed Contexts
100 | Active | 30 | 1.0.1 | Apache Aries Transaction Blueprint
101 | Active | 30 | 1.1.0 | Apache Aries Transaction Manager
103 | Active | 30 | 3.0.2 | Apache Karaf :: JNDI :: Core
104 | Active | 30 | 1.0.0 | Apache Aries JNDI API
105 | Active | 30 | 1.0.0 | Apache Aries JNDI Core
106 | Active | 30 | 1.0.0 | Apache Aries JNDI RMI Handler
107 | Active | 30 | 1.0.0 | Apache Aries JNDI URL Handler
108 | Active | 30 | 1.0.0 | Apache Aries JNDI Support for Legacy Runtimes
109 | Active | 80 | 3.0.2 | Apache Karaf :: JNDI :: Command
118 | Active | 50 | 2.3.0 | OpenJPA Aggregate Jar
|