1 Reply Latest reply on Nov 7, 2006 11:17 AM by gavin.king

    DB-Updates already happening in updateModelValues?

    m_hess

      Hi there,

      I think I currently have a problem of basic understanding what actually is ment to happen in what phase of the JSF Lifecycle when Seam is involved.

      What I would expect is as follows:

      When a ActionMethod is triggered through a commandlink, the JSF Lifecycle is started. Especially in UpdateModelValues the values from the html-form are transfered into the backing bean. Then afterwards in my actionMethod (called during invokeApplication phase), my application gets to decide wether the updatedModel is ment to be persisted or not.

      So - that´s what I thought until about an hour ago, when I realized that something was "off" in my application. Turning on lifecycle-Debugging as well as hibernates "show_sql", I can find the following in my log:

      [13:04:29] [tr1] [DEBUG] [...yfaces.lifecycle.LifecycleImpl:287 ] >> entering updateModelValues in org.apache.myfaces.lifecycle.LifecycleImpl
      Hibernate: update TimeRecordInput set total=? where id=?
      [13:04:29] [tr1] [DEBUG] [...yfaces.lifecycle.LifecycleImpl:314 ] >> exiting updateModelValues in org.apache.myfaces.lifecycle.LifecycleImpl


      So I now know, that the new values actually get persisted in updateModelValues already.

      Questions:

      1. Is this the correct and expected behaviour? What about .persist() and .merge()? Do I not need to call them in my actionBeans?

      2a. If so, where can/should I implement complex validation routines? My actionbeans seam to be the wrong spot, since this occurs too late. Or is it correct there, and I just have to use @rollback on it?

      2b. If not, what might cause this behauviour (maybe some specific settings for example)?

      Thanks for any advise you can give me.
      Michael

        • 1. Re: DB-Updates already happening in updateModelValues?
          gavin.king

          All depends upon how you are managing transactions. Results (usually) get flushed when transactions commit. If you use Seam transaction management (ie. SeamExtendedManagedPersistencePhaseListener) this happens at the end of the invoke application phase. If you use EJB3, it happens when session bean methods are called.