seam server failover fails with StaleState???

[deanhiller2000]

This is very odd, I would think only Hibernate should be throwing staleStateExceptions when saving to the database.  Why is seam throwing one????

Context:

1. run web app against load balancer
2. kill the server I am on
3. click next in the wizard I am on
4. session transfers to new server and result is StaleStateException(very odd considering I am the only one on the server AND considering I was not saving to the database either)

Here is the stack trace(notice this is purely in seam only not hibernate)....

2009-10-22 08:26:50,192 WARN [org.jboss.seam.jsf.SeamPhaseListener] (http-0.0.0.0-8080-3) uncaught exception, passing to exception hand org.hibernate.StaleStateException: current database version number does not match passivated version number

    at org.jboss.seam.persistence.HibernatePersistenceProvider.checkVersion(HibernatePersistenceProvider.java:322) at org.jboss.seam.persistence.HibernatePersistenceProvider.checkVersion(HibernatePersistenceProvider.java:226) 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:259) at org.jboss.seam.contexts.FacesLifecycle.resumeConversation(FacesLifecycle.java:175) at org.jboss.seam.jsf.SeamPhaseListener.afterRestoreView(SeamPhaseListener.java:393) at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:230) at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:196) at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265) 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.RewriteFilter.doFilter(RewriteFilter.java:63) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) 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:178) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) 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:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135) at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94) at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 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:158) at org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:672) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619)

Lastly, I was lookint at the Seam code in PassivatedEntity.java....

         
         Object result = em.getReference( getEntityClass(), getId() );
         if (result!=null && checkVersion) 
         {
            checkVersion(em, result);
         }

why are we checking version when we are not even saving the entity???? 

[jeanluc]

Hm... how could result be not null if there hasn't already been a call to em.persist()? Before then the entity is not yet associated with the persistence context. Something must have triggered the persistence.

Enable DEBUG/TRACE logging for Hibernate and see what happens in more detail.

[kapitanpetko]

Dean Hiller wrote on Oct 22, 2009 17:03:


why are we checking version when we are not even saving the entity???? 

The whole idea is that since the SMPC lives in the conversation (session), you need to replicate it along
with the session. But since the PersitenceContext is not serializable, you can't do it directly. So what
Seam does is save the classes and ID's of all entities and reattaches them to a newly created PersistenceContext
on activation. The StaleStateException means the version, saved in the http session, is different from the one
in DB. So, yes, there is no saving going on, but the idea is the same: to make sure you are restoring the same entity.

Now, the cause of this is either:

1. There is a save you are not aware of (Seam global transactions?) You could check for this by enabling Hibernate SQL logging.


2. The session on the second node is not synced yet when you kill the first node (are you using REPL_ASYNC) as cache mode?)

Of course, it could be bug in Seam, too. Use the newest version if you can and search JIRA for MEI, passivation and the like.

The idea behind all this is explained here:

Clustering and EJB Passivation