Java Transaction API (JTA)
Application server components can be transactional, meaning that if one part of a transaction fails, the entire operation can be rolled back; and all components participating in the transaction are also rolled back. J2EE however, defines different levels of transaction participation. The more your components participate in a transaction, the more overhead is required, but the more reliable your business processes are. EJBs define several levels of transactional participation on a method-by-method basis for each bean's methods:
Not Supported: The method does not support transactions and must be executed outside of any existing transaction.
Required: A transaction is required, so if one exists, this method will use it; otherwise, you have to create a new one for it.
Supports: A transaction is not required, but if one exists, this method will participate in it.
Requires New: A new transaction is required, so regardless if one exists or not, a new one must be created for this method.
Mandatory: A transaction is required and furthermore must be passed to this method; if a transaction does not exist when this method is invoked, it will throw an exception.
Never: A transaction is forbidden; if this method is called and a transaction exists, the method will throw an exception.
The implications of each should be apparent, and the performance impact is as you can guess: Supported is the most unintrusive and yields the best performance at the cost of possible loss of data; Required is safe, yet a little more costly; and Requires New is probably the most expensive.