1 Reply Latest reply on Aug 30, 2007 10:31 AM by motte1979

    s:link jta - transaction, rollbackonly

    motte1979

      Hi !

      Im using s:link with @DataModelSelection to delete an entity.

      <a jsfc="s:link" value="#{messages['action.delete']}" action="#{labelFilter.delete}"/>

      If i have opened two pages with the same content and simulate simultan user-action 'delete' on the same entity, i got an OptimisticLockException on flush.
      @TransactionAttribute (TransactionAttributeType.REQUIRES_NEW)
       public void delete(EmonitorEntity entity) {
       try {
       this.entityManager.remove(entity);
       this.entityManager.flush();
       } catch (OptimisticLockException ole) {
       if (sessionContext.getRollbackOnly())
       logger.info("rollbackonly", ole);
       }
       }

      The transaction (the new one) should have been rolled back after processing this method (because i'm using CMT which is default). This seems to be done correctly. Afterwards i'm raising an event to a PAGE-scoped component to refresh it's contents. But the refresh does not work because the transaction
      has been set to 'rollbackonly'.
      public Long size(Class<?> clazz, String[] properties, Object[] values) {
       Query q = getSizeQuery (clazz, properties, values);
      
       if (sessionContext.getRollbackOnly())
       logger.fatal("rollbackonly", new AssertionError());
      
       try {
       return ((Number) q.getSingleResult()).longValue();
       } catch (RuntimeException rte) {
       throw rte;
       }
       }


      This all is processed in the RENDER_RESPONSE_PHASE of jsf.


      * Does seam work correctly with @TransactionAttribute ?
      * I've spawn a new transaction for the delete-method, why does this effect the RENDER_RESPONSE-PHASE - transaction of seam?


      Thanks for your help! Hints are welcome ...

      Using :

      * seam 2.0.0.BETA1 from cvs
      * hibernate 3
      * jboss 4.2.0.GA


        • 1. Re: s:link jta - transaction, rollbackonly
          motte1979

          It seams that the lifecycle for s:link and s:button is different from h:commanButton:

          The log shows me for s:button and s:link the following informations

          2007-08-30 16:26:06,924 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] beginning transaction prior to phase: RESTORE_VIEW 1
          2007-08-30 16:26:06,966 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] committing transaction after phase: RESTORE_VIEW 1
          2007-08-30 16:26:06,969 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] beginning transaction prior to phase: RENDER_RESPONSE 6
          2007-08-30 16:26:06,996 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] committing transaction after phase: INVOKE_APPLICATION 5
          2007-08-30 16:26:07,002 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] beginning transaction prior to phase: INVOKE_APPLICATION 5
          2007-08-30 16:26:07,418 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] committing transaction after phase: RENDER_RESPONSE 6
          
          


          for h:commandButton looks like
          2007-08-30 16:22:13,633 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] beginning transaction prior to phase: RESTORE_VIEW 1
          2007-08-30 16:22:14,659 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] committing transaction after phase: INVOKE_APPLICATION 5
          2007-08-30 16:22:14,677 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] beginning transaction prior to phase: RENDER_RESPONSE 6
          2007-08-30 16:22:16,022 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] committing transaction after phase: RENDER_RESPONSE 6
          


          Does anyone know the reason for seam 2.0.0.BETA1 doing this?

          I'm using JSF-impl bundled with JBoss 4.2.0 -> jsf_impl_1.2_04-b10-p01