JBossDeveloper

This is interesting, this applies to when data versions are not consistently applied, and Hibernate should be applying these pretty consistently.

What version of Hibernate are you using, and what cache mode are you running in?

Could you email me more trace level logging on this? This problem really should have gone away with 1.4.1.BETA and Hibernate 3.2.

Thanks,
Manik

What was the resolution on this issue because I am seeing the same problems with 1.4.0 and 1.4.1 respectively (using hibernate 3.2.1).

Forgot to mention, I am using INVALIDATION_ASYNC with Optimisitic Locking

Please see http://jira.jboss.com/jira/browse/JBCACHE-894

This is fixed in 1.4.1.CR1 (in QA at the moment, will be released v. soon)

I am experiencing similar problems using JBC 1.4.0SP1 and JBC 1.4.1BETA using both hibernate-3.2.0 and hibernate-3.2.1.

The NPE's have been replaced with a data version class mismatch. I traced for a while and it looks like when the OptimisticValidatorInterceptor validates nodes it runs into nodes in the workspace with a version object of type org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter while the real node in the cache contains a version object of type DefaultDataVersion.

One possible reason that the real nodes still have a version object of DefaultDataVersion is that the constructor for OptimisticTreeNode ignores the version passed in. It looks like there are some recent CVS commits to OptimisticTreeNode that update the constructor to use the version parameter.

ddieckma, 1.4.1.CR1 should solve those data version mismatch problems.

I have a similar problem with a data version class mismatch.
I work with Hibernate 3.2.1 and JBossCache 1.4.1.CR1 (both downloaded yesterday).

Hibernate configuration :
- hibernate.cache.provider_class=org.hibernate.cache.OptimisticTreeCacheProvider
- objects are cached in transactional mode (<class...> ...)

TreeCache configuration is the hibernate-recommended-config.xml with :
- OPTIMISTIC NodeLockingScheme
- INVALIDATION_ASYNC CacheMode

My application seems to work when persistent objects are created, readed, updated... but not deleted :(

Here is the stack trace :

java.lang.RuntimeException:
 at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1146)
 at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
 at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1520)
 at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:433)
 at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:248)
 at org.objectweb.jotm.Current.commit(Current.java:526)
 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:500)
 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:473)
 at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:266)
 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
 at $Proxy2.supprimerCatalogue(Ljava.lang.String;)V(Unknown Source)
 at clara.prototype.applicatif.hibernatoo.impl.GererCataloguesImpl.supprimerCatalogue(GererCataloguesImpl.java:90)
 at clara.prototype.presentation.strutsoo.gerercatalogues.SupprimerCatalogueAction.execute(SupprimerCatalogueAction.java:63)
 at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
 at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
 at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
 at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
 at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
 at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
 at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243)
 at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
 at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275)
 at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:161)
Caused by: org.jboss.cache.optimistic.DataVersioningException: Attempting to apply data version of type class org.hibernate.cache.OptimisticTreeCache$
NonLockingDataVersion to a node [fqn = /clara/prototype/persistant/hibernatoo/Catalogue/clara.prototype.persistant.hibernatoo.Catalogue#9] that already contains version of type class org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter
 at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:144)
 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.InvalidationInterceptor.invoke(InvalidationInterceptor.java:60)
 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
 at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:859)
 at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1124)
 at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
 at org.objectweb.jotm.SubCoordinator.doBeforeCompletion(SubCoordinator.java:1520)
 at org.objectweb.jotm.SubCoordinator.commit_one_phase(SubCoordinator.java:433)
 at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:248)
 at org.objectweb.jotm.Current.commit(Current.java:526)
 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:500)
 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:473)
 at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:266)
 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
 at $Proxy2.supprimerCatalogue(Ljava.lang.String;)V(Unknown Source)
 at clara.prototype.applicatif.hibernatoo.impl.GererCataloguesImpl.supprimerCatalogue(GererCataloguesImpl.java:90)
 at clara.prototype.presentation.strutsoo.gerercatalogues.SupprimerCatalogueAction.execute(SupprimerCatalogueAction.java:63)
 at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
 at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
 at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
 at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

I would bring this up on the Hibernate forums. This is pretty specific to them, since both data versions on the node are Hibernate classes:

org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter

org.hibernate.cache.OptimisticTreeCache$NonLockingDataVersion

i still get data node is newer ... problem.

JBossCache 1.4.1.CR1 [optimistic lock - invalidation sync]
Hibernate 3.2
JBoss 4.0.5.GA

java.lang.RuntimeException: org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=zzz52.zzzint.com/1919, BranchQual=, localId=1919] status=STATUS_NO_TRANSACTION; - nested throwable: (java.lang.RuntimeException: )
at org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:180)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:211)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
at sun.reflect.GeneratedMethodAccessor336.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=zzz52.zzzint.com/1919, BranchQual=, localId=1919] 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.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
... 57 more
Caused by: java.lang.RuntimeException:
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1091)
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)
... 59 more
Caused by: org.jboss.cache.CacheException: DataNode [/zzz/zzzint/zzz/domain/model] version org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter@2f5b6cc8 [current=21, previous=21, src=SingleTableEntityPersister(zzz.zzzint.zzz.domain.model.PlayerPart)] is newer than workspace node org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter@79a067a8 [current=3, previous=3, src=SingleTableEntityPersister(zzz.zzzint.zzz.domain.model.Part)]
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:127)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:101)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:66)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:95)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.InvalidationInterceptor.invoke(InvalidationInterceptor.java:60)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
... 63 more

What you see is a validation error due to concurrent writes. This will occasionally happen when using optimistic locking.

This is caused when:

1) Thread1 starts tx
2) Thread1 copies data to workspace
3) Thread2 starts tx
4) Thread2 copies data to workspace
5) Thread2 updates data
6) Thread2 commits
7) Thread1 updates data
8) Thread1 commits - FAILS.

Step 8 fails because the data that Thread1 has is stale since Thread2 has updated it. This is the version mismatch that you see.

To return on my problem with org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter and org.hibernate.cache.OptimisticTreeCache$NonLockingDataVersion on delete operation...
Everthing is ok if I modify the class org.jboss.cache.interceptors.OptimisticValidatorInterceptor to delete an if statement that generate the DataVersioningException : if(!realNode.getVersion().getClass().equals(workspaceNode.getVersion().getClass())) line 142.

The problem is that Hibernate considers that the DataVersion can change from a type to an other (NonLockingDataVersion to DataVersionAdapter), but it's not the idea on JBC.
So my question : Is it important to have the same type before and after the update of the node ? Does the "newerThan(DataVersion)" method not supposed to manage the different type to be able to compare him to an other kind of DataVersion ?

Rudy KROL

hi manik - thanks for your reply.

the problem is there is a massive amount this error[data node is newer ...]. someone got the same problem in this thread and this problem was supposed to be fixed in 1.4.1.CR1 - please correct me if im wrong.

"kgrjb" wrote:

the problem is there is a massive amount this error[data node is newer ...]. someone got the same problem in this thread and this problem was supposed to be fixed in 1.4.1.CR1 - please correct me if im wrong.