2010-09-30 14:12:27,895 WARN [org.jboss.cache.interceptors.OptimisticTxInterceptor] (ajp-0.0.0.0-8009-2) Caught exception, will now set transaction to roll back
org.jboss.cache.optimistic.DataVersioningException: Transaction attempted to create /adonis/org/hibernate/cache/StandardQueryCache/QUERY/sql: select <QUERY DETAILS>; max rows: 2 anew. It has already been created since this transaction started, by another (possibly remote) transaction.
We have a concurrent creation event.
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.visitOptimisticPrepareCommand(OptimisticValidatorInterceptor.java:116)
2010-09-30 14:12:27,897 WARN [com.arjuna.ats.arjuna.logging.arjLoggerI18N] (ajp-0.0.0.0-8009-2) [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_2] TwoPhaseCoordinator.beforeCompletion - failed for com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple@493ee8c1
org.jboss.cache.optimistic.DataVersioningException: Transaction attempted to create /adonis/org/hibernate/cache/StandardQueryCache/QUERY/sql: select <QUERY DETAILS>; max rows: 2 anew. It has already been created since this transaction started, by another (possibly remote) transaction.
We have a concurrent creation event.
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.visitOptimisticPrepareCommand(OptimisticValidatorInterceptor.java:116)

Environment:

The application is deployed in an ear with an ejb and war component.

The ejb has a persistence unit, which uses an XA jta-datasource and 3 entity jar-files defined (that are deployed independantly)

Another application is deployed that the primary application depends on, an EAR with ejb and persistence. The persistence unit references a different XA datasource and references 1 of the 3 jar-files as above.

The issue might be caused by having 2 persistence contexts being applied to a single entity, but not entirely sure on this though

I have tried adjusting the transaction manger's configuration to allowMultipleLastResources = true (before we switched to XA datasources, this was necessary with tx datasources and this environment), but the error occurs with this enabled or disabled.

I am not sure whether this is a jboss cache issue, hibernate or transaction manager issue.

how could I avoid this issue? (the exception occurs irregularly, it's difficult to reproduce).

I am experiencing the same issue. I think this is caused by use of optimistic locking mode for the Hibernate 2nd level cache configuration. Two threads try to add the same element to the cache at about the same time. Once the second thread completes the transaction, the first one had already added the element to the cache and the transaction is aborted.

I suppose it would not happen if the lock (JBoss cache) locking scheme is changed to pessimistic, but that will result in less throughput.

My question really is about how and or when Hibernate uses the new JBoss cache method "putForExternalRead" which should silently return if the node is already in the cache. Anybody?

We found the issue a few months ago. We were caching some page components, and we basically had an overlap, where the key was used twice in 1 page. So the first time the key was retrieved, it would be locked, and under certain circumstances (which we never clarified), the 2nd retrieval of the key would fail because the lock was still in place.