We are having severe problems using JBossCache 1.3's optimistic locking with Hibernate. We tried with Hibernate 3.2 CR2 as well as backporting the optimistic provider to 3.1.3 -- problems are the same.
The first problem was with cache invalidation within a JTA transaction. Namely, cache invalidation wasn't performed outside the scope of transaction, and because transaction was already committed at that moment, errors occured. I first thought this was a bug in Hibernate's OptimisticTreeCache, so I reported the issue here: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764 (check it out as it contains a detailed description). I also fixed this problem by adding a tx.suspend() call to Hibernate's class. However, according to this wiki page: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheOptionsAPI, the failSilently option, which Hibernate does use in this place, should also have the effect of cache bypassing the transaction, but this just doesn't happen -- cache invalidation happens within JTA transaction and an exception is thrown (or perhaps it's just logged, but that's still unacceptable, since this happens after *every* commit). So now I believe the Hibernate guys are innocent and that the bug lies within JBossCache ;) This was the first problem, for which I could create a workaround, so it's not that critical. Now comes the real trouble, which I couldn't even get to understand, much less solve... After using optimistic locking in semi-production environment for a while, we started getting "DataNode version is newer than workspace node" errors. If I understand correctly, this should only occur when two versions of an object are more or less simultaneously read, modified and committed. However, we are getting these errors in places and with objects where we don't do any modification at all. One type of object that causes these errors is in fact modified nowhere in the entire application (after creation) and its cache is configured read-only, but we still get these errors! What's worse, it seems that once an object triggers this error, the errors always occur from that point on, whenever that same object is used. For example, if MyClass first causes the error at version 4-5, it goes like this: [MyClass#123] version DefaultDataVersion(5) is newer than workspace node DefaultDataVersion(4) | ... | [MyClass#123] version DefaultDataVersion(6) is newer than workspace node DefaultDataVersion(5) | ... The object never starts working again unless the application is restarted. And something else is also very interesting. We get this same error on the root node (fqn="/")! 2006-05-18 08:47:45,613 INFO [org.jboss.cache.interceptors.OptimisticValidatorInterceptor] DataNode [/] version DefaultDataVersion(30) is newer than workspace node DefaultDataVersion(29) | 2006-05-18 08:47:45,626 ERROR [org.hibernate.transaction.JTATransaction] JTA commit failed | org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=server1/15236, BranchQual=, localId=15236] status=STATUS_NO_TRANSACTION; - nested throwable: (java.lang.RuntimeException: ) | ... | Caused by: org.jboss.cache.CacheException: unable to validate nodes | at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:109) | at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:64) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) | at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:87) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) | at org.jboss.cache.interceptors.InvalidationInterceptor.invoke(InvalidationInterceptor.java:54) | at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) | at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:781) | at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1043) | ... 71 more This error happens only once, soon after application start, and this is the only one we can reproduce in a development environment (but not figure out what causes it and why). Other errors seem random, but they happen too frequently, and once they occur, they don't go away... Please help! Right now we can't possibly use optimistic locking in production and we have to go back to 1.2.4 and pessimistic. Regards, Jaka View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3944813#3944813 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3944813 ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
