It's main purpose is to make the seam-managed persistence context (SMPC) aware of transactions committed by the EJB container. For example, if you call a method on a stateless session bean, and a jta transaction isn't in place, one will be created and when that method returns it will be committed. The SMPC needs to know that, so that it can flush if necessary.
The reason it lives in WEB-INF/components.xml is that its specific to seam, and WEB-INF/components.xml is how seam is configured.
Turning it off won't keep your EJB transactions from completing, but it will possibly mean bad things for non-EJB components that use transactions, like the SMPC.
Thanks for the response. I guess what my problem is is that Seam configuration that applies to EJB, is placed within a configuration file of the WAR. Can you confirm that?
Yes, it is by convention placed in seam's components.xml in WEB-INF in the war, because seam has to have a WAR in order to bootstrap, and so that's the default place for configuration specific to seam. It also would not make sense for this attribute to be placed in an EJB jar, because you can have multiple EJB jars in an EAR, and this transaction switch is global to the seam deployment, so there's no way to
turn it offfor one EJB and
turn it onfor another. It essentially means
this seam deployment listens for EJB transaction commits,and Seam can either listen or not. Hence, it goes in seam's configuration file (in the WAR) and not in the EJB jar.
Thanks - seems like something i have to get used to, configuring your application tier from your presentation tier:
<component name="mybean"> <property name="someprop">some value</property> </component>
I don't think of the WAR as the
presentation tier,and seam certainly is not a strict presentation-tier technology. The war is just a packaging standard, which is used the world over to hold all kinds of layers, regardless of how they're named :)