Exception "current database version number does not match passivated version number" when using @Version
Hi,
I presently use Seam 2.0.2.SP1 and need to manage concurrency between several users. I tried to use @Version annotation that I set on the getVersion() method of the entity bean to have optimistic locking. I thought that the use of this annotation would simply raise an exception (OptimisticLockException) whenever we try to update this entity bean in database from an instance with a too old version number. But it seems that some checking is done not only during the update of this entity bean in database since I sometimes get the following exception after having updated the entity bean and switched to another conversation (parent one for instance):
12:44:20,153 ERROR [STDERR] Jul 1, 2008 12:44:20 PM org.exadel.jsf.PhaseTracker afterPhase INFO: AFTER RESTORE_VIEW 1 12:44:20,160 ERROR [SeamPhaseListener] uncaught exception org.hibernate.StaleStateException: current database version number does not match passivated version number at org.jboss.seam.persistence.HibernatePersistenceProvider.checkVersion(HibernatePersistenceProvider.java:281) at org.jboss.seam.persistence.HibernatePersistenceProvider.checkVersion(HibernatePersistenceProvider.java:190) at org.jboss.seam.contexts.PassivatedEntity.checkVersion(PassivatedEntity.java:133) at org.jboss.seam.contexts.PassivatedEntity.getEntityFromEntityManager(PassivatedEntity.java:118) at org.jboss.seam.contexts.PassivatedEntity.toEntityReference(PassivatedEntity.java:73) at org.jboss.seam.contexts.EntityBean.activate(EntityBean.java:67) at org.jboss.seam.contexts.ServerConversationContext.unflush(ServerConversationContext.java:258) at org.jboss.seam.contexts.FacesLifecycle.resumeConversation(FacesLifecycle.java:158) at org.jboss.seam.jsf.SeamPhaseListener.afterRestoreView(SeamPhaseListener.java:389) at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:226) at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:192) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Unknown Source)
So it seems that Seam performs some additional checking when resuming a conversation. Does it mean that Seam always raises an error when it resumes a conversation and activates an entity bean with a too old version number ? I thought that it was still possible to use an entity bean instance even if the version number was old and not up to date. But if it is not the case, it would mean that it would not be possible to use an entity bean instance (even doing no update) with an invalid version number.
Could you help me understand if this is a normal behavior and how @Version should be used ?
Thanks.
