Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.