6 Replies Latest reply on May 28, 2009 8:58 PM by Jean Luc

    about "@Transactional is irrelevant during a JSF request when using Seam global transactions"

    Jean Luc Apprentice

      Can someone please clarify this statement? I re-read the chapter in Sia and the reference docs, but the exact behaviour is not fully clear.



      • since the typical Seam application uses JSF, doesn't that mean that the @Transactional annotation is pretty much ignored?




      • I haven't found a clear definition of what exactly the global transaction is and why it is actually named so. Based on the figure on page 371 in SiA, there are 2 or 3 transactions for a JSF request: one starting with Restore View (in JTA's case) and going until and including Invoke Application, then another optional one for page actions and a final one for Render Response. I understand the rationale for these transactions, but which are the global ones? All of them? Just the first? And in what sense is it global?




      • if using Seam-managed transactions, do I have to remove all standard @TransactionAttribute annotations from EJBs? If I don't, how does the container know not to commit the transactions (since from its point of view, the EJBs are declared to use CMT)? How can the container's tx manager be aware of Seam's and ignore what it has been instructed to do with the standard J2EE annotations?




      • is there a case with Seam-managed transactions when global transactions are not used? Or using Seam-managed transactions and using Seam global transactions are one and the same thing, enabled by <tx:entity-transaction...> and the use of @Transactional ?



      Thank you all.


      -jl

        • 1. Re: about "@Transactional is irrelevant during a JSF request when using Seam global transactions"
          Arbi Sookazian Master

          First of all, these are all excellent questions; the tx's part of the book was definitely confusing.  For example, the atomic conversation is referred to as web transaction in the Yuan book and application transaction in SiA.  There really, really needs to be a sticky on the topic of tx's in Seam as it gets very, very convoluted when you consider the possible scenarios: RESOURCE_LOCAL, JTA, EJB3 tx annotations, Seam tx annotations, no tx support, entity-tx, hibernate-tx, MANUAL flush with Hibernate or not!  A lot of the choices depend on whether you're running your business components for your app in a EJB environemnt (JTA) or not (RESOURCE_LOCAL).



          since the typical Seam application uses JSF, doesn't that mean that the @Transactional annotation is pretty much ignored?

          I don't understand your reasoning here.  That's like saying how can you use @javax.ejb.TransactionAttribute with EJB3 components in JSF/Seam apps?


          Seam has its own tx management that you can turn off (it's turned on by default) in the components.xml:


          <core:init transaction-management-enabled="false"/>




          I haven't found a clear definition of what exactly the global transaction is and why it is actually named so. Based on the figure on page 371 in SiA, there are 2 or 3 transactions for a JSF request: one starting with Restore View (in JTA's case) and going until and including Invoke Application, then another optional one for page actions and a final one for Render Response. I understand the rationale for these transactions, but which are the 'global' ones? All of them? Just the first? And in what sense is it 'global'?

          Answer to this is CLICKHERE by DAllen:



          When I say global transaction, global refers to 'surrounding the whole request'. Don't read to much into the phrase 'global transaction'. Another way to say it would have been 'automatic transaction wrapped around the request'.


          if using Seam-managed transactions, do I have to remove all standard @TransactionAttribute annotations from EJBs? If I don't, how does the container know not to commit the transactions (since from its point of view, the EJBs are declared to use CMT)? How can the container's tx manager be aware of Seam's and ignore what it has been instructed to do with the standard J2EE annotations?

          Rule of thumb: use @TransactionAttribute on EJB3 business methods; use @Transactional on JavaBean business methods.  You can't mix and match in the same component for obvious reasons.


          If you are using EJB3 components, then use this in your components.xml:


          <transaction:ejb-transaction/>



          EjbTransaction.java:


          /**
           * Dummy component that lets us install the
           * EjbSynchronizations via the tag
           * transaction:ejb-transaction
           *
           * @see EjbSynchronizations
           * @author Gavin King
           * 
           */
          @Name("org.jboss.seam.transaction.ejbTransaction")
          @Scope(ScopeType.STATELESS)
          @Install(precedence=BUILT_IN, value=false)
          @BypassInterceptors
          public class EjbTransaction {}



          I have used and not used that tag in my components.xml for an EJB3 project and have not noticed a difference.  I am not sure really exactly what it does.  What does lets us install the
          EjbSynchronizations
          mean?


          Well read the source code...


          EjbSynchronizations.java:


          /**
           * Receives JTA transaction completion notifications from 
           * the EJB container, and passes them on to the registered
           * Synchronizations. This implementation
           * is fully aware of container managed transactions and is 
           * able to register Synchronizations for the container 
           * transaction.
           * 
           * @author Gavin King
           *
           */
          @Stateful
          @Name("org.jboss.seam.transaction.synchronizations")
          @Scope(ScopeType.EVENT)
          @Install(precedence=FRAMEWORK, dependencies="org.jboss.seam.transaction.ejbTransaction")
          @BypassInterceptors
          @TransactionAttribute(TransactionAttributeType.SUPPORTS)
          public class EjbSynchronizations implements LocalEjbSynchronizations, SessionSynchronization{...}



          So apparently you lose ability to register Synchronizations.


          Synchronizations.java:


          /**
           * Interface for registering transaction synchronizations
           * 
           * @author Gavin King
           *
           */
          public interface Synchronizations
          {
             public void afterTransactionBegin();
             public void afterTransactionCommit(boolean success);
             public void afterTransactionRollback();
             public void beforeTransactionCommit();
             public void registerSynchronization(Synchronization sync);
             public boolean isAwareOfContainerTransactions();
          }




          is there a case with Seam-managed transactions when global transactions are not used? Or 'using Seam-managed transactions' and 'using Seam global transactions' are one and the same thing, enabled by <tx:entity-transaction...> and the use of @Transactional ?

          Seam-managed tx's are enabled by default.  Pg. 162 of Yuan book describes how to turn it off if you need to.  I'm not aware of a good reason that you'd want to do that in a Seam app, however.


          I didn't see usage of the term 'global transaction' in the Yuan book but they describe it essentially on pg. 161.


          Unfortunately, after reading the books' sections and writing this lengthy response, I'm still not sure exactly why you need 2-3 tx's per JSF request/response cycle in a Seam app.  Perhaps a good way to know is to turn off Seam-managed tx's and see what happens...


          There really needs to be a sticky on this subject, it's one of the more complicated subjects (as it involves JSF life cycle and EJB3 tx demarcation using CMT typically) in the Seam subject matter...

          • 2. Re: about "@Transactional is irrelevant during a JSF request when using Seam global transactions"
            Arbi Sookazian Master

            Oh, and let's not forget distributed tx's (2PC/XA).  How does this affect the Seam tx manager if at all (or is it all isolated to JTA only)?

            • 3. Re: about "@Transactional is irrelevant during a JSF request when using Seam global transactions"
              Jean Luc Apprentice

              Click HELP for text formatting instructions. Then edit this text and check the preview.



              jeanluc: since the typical Seam application uses JSF, doesn't that mean that the @Transactional annotation is pretty much ignored?


              Arbi Sookazian: I don't understand your reasoning here. That's like saying how can you use @javax.ejb.TransactionAttribute with EJB3 components in JSF/Seam apps?

              No, what I meant is this: if Seam global transactions are used, then the automatic aka 'global' transactions are started anyways for JSF requests, so there is no need for @Transactional annotations. If they are present, they are ignored. This annotation only becomes relevant when not using Seam global transactions but since this is a Seam annotation and thus processed by Seam, I guess it only becomes useful when using user-managed transactions via Seam's own UserTransaction implementation.



              jeanluc: if using Seam-managed transactions, do I have to remove all standard @TransactionAttribute annotations from EJBs? If I don't, how does the container know not to commit the transactions (since from its point of view, the EJBs are declared to use CMT)? How can the container's tx manager be aware of Seam's and ignore what it has been instructed to do with the standard J2EE annotations?


              Arbi Sookazian: Rule of thumb: use @TransactionAttribute on EJB3 business methods; use @Transactional on JavaBean business methods. You can't mix and match in the same component for obvious reasons.

              Hmmm... if one chooses to use Seam transactions and the EJBs are registered as Seam components (with @Name), shouldn't one use Seam's annotations (@Transactional) instead of the standard J2EE (@TransactionAttribute)? If J2EE annotations are present, they will be processed by the container who will believe it's a case of CMT and thus will manage the transaction itself. Taje a typical case of Stateless session beans. Each method call is by default wrapped in a transaction by the container. Why would the container ignore the standard J2EE annotation and ejb-jar.xml and choose not to commit at the end of a SLSB method call just because somewhere in the web tier there is thing called Seam that has its own annotations and tx management?



              I looked in the Seam source today, particularly at the transaction manager and found that it merely delegates to UserTransaction. The code looks as if Seam adds its own bean-managed transaction control. However, what happens if the EJBs are deployed as container-managed transactions?



              There really needs to be a sticky on this subject, it's one of the more complicated subjects (as it involves JSF life cycle and EJB3 tx demarcation using CMT typically) in the Seam subject matter...

              I agree. It is unfortunate that such an important subject is not covered with clarity and that names are made up so easily. global, atomic (hello, aren't all transactions atomic?), web and so on.


              I'll keep digging in the code,
              -jl

              • 4. Re: about "@Transactional is irrelevant during a JSF request when using Seam global transactions"
                Arbi Sookazian Master

                Most likely the best person to shed some light on these questions is DAllen.


                I just checked out all his posts here http://in.relation.to/Bloggers/Dan
                and lo and behold none on transactions (but all of them are very interesting/informative).


                Does anybody know of a wiki or blog by a Seam core dev on this topic?


                Here is a recent unanswered thread on Seam tx's: http://seamframework.org/Community/QuestionRegardingSeamGlobalTransactionHowToRollback


                It's funny how GKing responds to many of the Web Beans forum threads but there are few Seam core dev responses in this Seam forum...  PMuir used to respond all the time 2 yrs ago to the old Seam forum and even this one for a while.


                Well if you guys don't respond, at least write a blog entry on Seam tx's...

                • 5. Re: about "@Transactional is irrelevant during a JSF request when using Seam global transactions"
                  Arbi Sookazian Master

                  Jean Luc wrote on May 27, 2009 03:20:


                  since the typical Seam application uses JSF, doesn't that mean that the @Transactional annotation is pretty much ignored?



                  as per pg. 374 of SiA book:



                  the @Transactional annotation is irrelevant during a JSF request when using Seam global transactions.

                  So the answer to your question is yes if you're using Seam global tx's (which is turned on by default).


                  As per pg. 370 of SiA book:



                  To disable Seam global tx's, you set the following configuration in the component descriptor:

                  <core:init transaction-management-enabled="false"/>

                  As a word of warning, taking away Seam-managed tx's leaves the view rendering w/o a tx.

                  It then goes on to describe the problem of rendering w/o a tx which basically has to do with lazy loading (each lazy load operation can result in more than one query and you ideally should wrap them in one tx).


                  The treatment of the global tx and related subjects in sections 9.4.1, 9.4.2 and 9.4.3 in SiA are overall pretty good but there is a lot of detail and examples that are left out.


                  For example, how exactly does using global tx's disable flushing of the persistence context during view rendering?  And in what context (example?) does that statement apply?  When using MANUAL flush, AUTO flush, etc.?


                  Another example: Seam also weaves in a number of convenience methods that ease the task of managing the tx from the application code.  What are these convenience methods specifically?


                  Another example: As a word of warning, mixing Seam's global tx's with CMT is complex since the tx's themselves are not shared.  What does this mean exactly?  I am currently using Seam global tx's with CMT, what are some problems/issues to expect?


                  • 6. Re: about "@Transactional is irrelevant during a JSF request when using Seam global transactions"
                    Jean Luc Apprentice

                    Another example: 'As a word of warning, mixing Seam's global tx's with CMT is complex since the tx's themselves are not shared'. What does this mean exactly? I am currently using Seam global tx's with CMT, what are some problems/issues to expect?

                    I speculate it means that Seam and the container notify each other about a transaction committed/rolledback by the other so either party is up-to-date with what has happened, but the transaction object itself is not the same -each party maintains its own object. However, it's not at all clear what does it mean for us. By default, Seam has global tx enabled and also by default a container will have CMT around its session beans. So is that statement saying the default setup is 'complex'?