3 Replies Latest reply on Jun 3, 2009 12:38 AM by tony.herstell1

    Seam Transactions Question


      This is what I have in components.xml:

      <!--<transaction:ejb-transaction />-->
      <persistence:managed-persistence-context name="entityManager" auto-create="true"
      <!--<transacti  on:entity-transa  ction entity-mana  ger="#{e  m}"/>-->

      I THINK i am using seam managed transactions (as apposed to the default EJB one)?

      In my controllers I use:

          private EntityManager entityManager;

      Should I be using

      @In entityManager entityManager;


      I am using



      on routines that I update and don't update DB.

      Is this correct?

      Doco (9.2 etc.) is a bit confusing....

      please advise.

        • 1. Re: Seam Transactions Question
          In fact you can mix, but you shouldnt, the Seam transaction management with Container management. Anyway:

          @PersistenceContext -> ALWAYS get the container managed persistence context.

          @In -> The annotation that you want to use Seam management.

          @TransactionAttibute, this is EJB stuff, so you dont need it if using seam management, in the global-transaction mode (the default one).

          Well, all of this is a really weird, even for me. :)

          But i hope that i helped.

          • 2. Re: Seam Transactions Question

            This is what I have in components.xml:

            Seam-managed transactions (SMT) are disabled with a different element: <core:init transaction-management-enabled="false" />. When the transaction-management-enabled attribute is missing, it is considered true by default. You haven't posted that element, but I guess you left it at default so SMT are enabled. This means the automatic transactions with which Seam wraps JSF requests are enabled. In other words, the transactions are initiated from the action beans that call, not from the EJBs. If you have EJBs are are marked REQUIRED for their transactions, they will be enrolled in the tx started by Seam.

            I am using @TransactionAttribute(TransactionAttributeType.REQUIRED) @TransactionAttribute(TransactionAttributeType.NOTSUPPORTED)

            You appear to have adopted the approach advocated by the EJB spec which does not have manual flushing (there's a discussion in SiA about this).

            As for injecting the EntityManager, @PersistenceContext will inject a PC managed by the container, whereas @In will inject one managed by Seam. The former is instantiated by the container and propagated according to the JPA spec (there is a section on precisely this point) - the rules can be complex is multiple beans of different types interact. One thing not mentioned in the original question is whether you need an extended PC or just a transaction-scoped one. The latter is what is says and is propagated automatically with the transaction (as required by the JPA spec) and lives as long as the stateful bean it is bound to. Regarding the former, be aware that an extended PC can only be started from a stateful session bean. Anyway, the JPA spec is clear about the propagation rules.

            If the PC is transaction-scoped, it will be flushed when the transaction commits.
            If the PC is extended-scope, it depends on the flushing mode.

            If you inject the PC with @In, that PC is instantiated by Seam which will also take care to inject the same PC in all components involved in a conversation. It's also Seam's responsibility to make the PC join the JTA transaction.

            You are right to be confused: there are multiple aspects (container- or application-managed persistence context, container- or application-managed transactions, transaction- or extended-scoped persistence contexts) with multiple combinations. Add to this the fact that to the container whatever Seam does is application-managed whereas to your application it appears as Seam-managed.


            • 3. Re: Seam Transactions Question

              Thank you for your replies.
              It all makes thinks less foggy now.
              Perhaps I can clear some long running defects I never managed to track down.