5 Replies Latest reply on Oct 21, 2009 2:39 AM by Dean Hiller

    StaleStateException after update success and tx is done???

    Dean Hiller Expert

      I have been using seam for over one year now and never seen something like this.  It is the standard #{action.edit(data)} from a dataTable with a @Begin(flushType=MANUAL) and that goes to the standard form with the outjected bean, and the commit has an @End.


      Here is the weird part, the changes all work and the transaction commits fine, BUT


      1. the conversation does not end(when viewing debug.xhtml, I see it)
      2. after clicking save, I end up in infinite redirect
      3. if I select the conversation in debug.xhtml, I then also end up in an infinite redirect
      



      The stack trace I see over and over is


      org.hibernate.StaleStateException: current database version number does not match passivated version number
           at org.jboss.seam.persistence.HibernatePersistenceProvider.checkVersion(HibernatePersistenceProvider.java:296)
           at org.jboss.seam.persistence.HibernatePersistenceProvider.checkVersion(HibernatePersistenceProvider.java:200)
           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:391)
           at org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase(SeamPhaseListener.java:228)
           at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:194)
           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:104)
           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.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
           at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)
           at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
           at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
           at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
           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.HotDeployFilter.doFilter(HotDeployFilter.java:53)
           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.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
           at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
           at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
           at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
           at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
           at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
           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:447)
           at java.lang.Thread.run(Thread.java:619)
      



      I am using seam 2.1.1GA


      any ideas or someone who has seen this before?  I have seen posts on nested conversations but we are not using a nested conversation.


      thanks,
      Dean



        • 1. Re: StaleStateException after update success and tx is done???
          Nikolay Elenkov Master

          Haven't seen anything like it, but apparently the passivated has a different version number from the one in DB. Is someone/something else
          saving the same object? Put a break point in HibernatePersistenceProvider.checkVersion to see both (old and new) versions. Might as well be a bug in Seam, though. Try with a newer version and/or disable MEI.


          <core:init distributable="false"/>
          

          • 2. Re: StaleStateException after update success and tx is done???
            Dean Hiller Expert

            finally fixed it, yeah, but weird.  So, yesterday I did do something different than all the other times.  Since the typical thinking is can use an action bean for edit and save(and the same form page), in the commit, I started using bean = entityMgr.merge(bean) .  I switched back to my usual method of


            if(bean.getId() != null)
               entityMgr.persist(bean);
            



            Man, I really miss hibernates saveOrUpdate method.  That method worked very well where merge seems like nothing but problem after problem(at least when using hibernate as backing impl).


            thanks,
            Dean


            • 3. Re: StaleStateException after update success and tx is done???
              Dean Hiller Expert

              I meant to say edit and add (same action bean and xhtml page) above so I thought I could use merge which is sorta like saveOrUpdate with those damn differences of returning a new bean(which I have had problems with in the past actually...other issues).

              • 4. Re: StaleStateException after update success and tx is done???
                Nikolay Elenkov Master

                Dean Hiller wrote on Oct 19, 2009 17:50:


                Man, I really miss hibernates saveOrUpdate method.  That method worked very well where merge seems like nothing but problem after problem(at least when using hibernate as backing impl).



                Since you are using Hibernate anyway, why not just use the native session?

                • 5. Re: StaleStateException after update success and tx is done???
                  Dean Hiller Expert

                  I don't know, I guess it started with that age old, we should be implementing the specification which after all these years, I think is nearly useless because we rarely switch implementations anyways and when we do, it is nearly the same amount of work to switch as if I had used the native api, so I don't really know.  I guess I could start getting the Session from the EntityManager but that is just as annoying as doing an if statement I do now.  I could change all the code back to use native hibernate api, but alas, I am too lazy to do that.  I just wish hibernate would pass back the same instance I passed to it in the merge but I guess the EJB spec may say they are not allowed to modify the object being passed in maybe :(...don't know for sure.