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...

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)?

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...

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?