Optimistic DataVersioningException on read-only objects

[jakajaksic]

Hi, all!

We noticed an interesting problem with optimistic locking. The problem is frequent versioning exceptions on objects which are very rarely modified or even read-only. If we run a stress test, the errors appear almost immediately, while in real-life use they occur at least a few times a day, which is bad enough. Because of this, we had to temporarily switch JBC off, because we couldn't find a working configuration, but since 1.4.1 SP1 our application seems to run well in pessimistic mode. So this is no longer a critical problem, but I still think it deserves some attention.

The thing is that these errors seem really unnecessary. I do not know precisely how the combination of Hibernate + JBoss Cache works, but the nature of our application is such that real concurrent modifications of the same objects are extremely rare (it is basically a BPM application, using JBPM 3.0, where objects or records are mainly just inserted, and modifications are mostly done in a "private" context, where each user/process/thread only touches its own objects). So where do these errors come from? I'm pretty sure the objects causing errors are NOT being modified, much less concurrently - they are merely being concurrently accessed, but that should not be a problem, right?

I also have a question as to which locking mode is better to use in an application such as ours, where the possibility of concurrent object modifications is almost none. Of course we will stay with pessimistic for now, because it works. I'm just wondering if this is the optimal choice anyway, or are we missing something?


Regards,
Jaka

[hargitt]

Hi,

We are having a similar problem with Optimistic locking in JbossCache 1.4.1.SP1 together with Hibernate 3.2.2 on JBoss 4.0.4.GA.

Whenever we commit a trasaction, we are seeing a harmless (it seems) warning:

WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null)

Futher more, when we are updating two or more different objects simultaneously (same class) we get a versioning exception:

2007-02-15 16:12:01,563 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void com.upstreamsystems.mip.clubs.EJB.hibernateslsb.HClubManager.setMemberVariables(java.lang.Long,java.util.Map) throws java.rmi.RemoteException:

org.hibernate.TransactionException: JTA commit failed:

 at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:153)
...
Caused by: org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=traviata/299, BranchQual=, localId=299] status=STATUS_NO_TRANSACTION; - nested throwable: (java.lang.RuntimeException: )

 at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:372)

 at org.jboss.tm.TxManager.commit(TxManager.java:240)

 at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)

 at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146)

 ... 50 more

Caused by: java.lang.RuntimeException:

 at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1148)

 at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)

 at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1491)

 at org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1110)

 at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:324)

 ... 53 more

Caused by: org.jboss.cache.optimistic.DataVersioningException: DataNode [/com/upstreamsystems/mip/clubs/VO/Impl/ClbMemberVariable] version Ver=31 is newer than workspace node Ver=30

 at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:147)

 at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:110)

 at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)

 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)

 at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:99)

 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)

 at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:861)

 at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1126)

 ... 57 more

If we run everything under one thread, then then error does not occur.

I am trying to join this experience with forum entry: http://jboss.org/index.html?module=bb&op=viewtopic&t=92818&postdays=0&postorder=asc&start=30 but if I go back to 1.3.0.SP2 I start getting the null pointer exception bug that was fixed in the next release.

Any Ideas?

[manik]

This is expected behaviour. If you have concurrent threads changing the same node at the same time, one of the threads will fail.

In pessimistic locking, the 2 threads are NOT ALLOWED to change nodes at the same time and one thread waits. This leads to poor concurrency. Optimistic locking allows both threads to access nodes at the same time and hopes that one thread will just read and not write. If simultaneous writes happen, you will naturally get a concurrent modification exception.

[hargitt]

Thanks Manik for you answer.

I guess I was not clear by saying "same class". I am updating the same class, different instance.

I do not understand why this is happening but due to time constraints I have gone back to Pessimistic locking and will only be able to revisit this issue in a few weeks.

As mentioned above, in Optimistic locking, I get the "WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null)" warning whenever I update an object. I am unclear if this is a bug to ignore or something else.

[manik]

Yes, the warning is unnecessarily noisy and has been removed in later versions.