...
- REQUIRED - the default, which is to start a transaction if one does not exist, but to use the existing one if it has already been started.
- REQUIRES_NEW - the following are true, when using this annotation... transaction is created on every callthe transaction , and ends when the call is completedbeans do not . Beans don't partake in transactions created by other parts of the system, as any existing transactions prior to the call are suspended
- any calls down the chain, from here, may or may not be part of the new transaction, depending on their further transaction configurations any calls down the chain, from here, cannot be part of a transaction that existed prior to this call.
- MANDATORY - a transaction must always exist prior to the call, and it will be used. It is an error otherwise
- NOT_SUPPORTED - component not included in the transaction
- SUPPORTS - transaction will be used if it exists, but will not be created if it does not exist
- NEVER - if a transaction exists, it is an error to call the method
@TransactionAttribute applies to both methods and entire beans. You may set one type of transaction behaviour (as seen above) on the bean, and a different one on a specific method of that same bean, which overrides the one configured for the overall bean. For instance, maybe you want to make an audit entry in the database log that you are about to attempt a credit card payment. It really needs to be in it's own transaction so that it is IMMEDIATELY committed for audit purposes, if something goes wrong with the credit card payment. So, perhaps you use MANDATORY on the bean, and REQUIRES_NEW on the method for audit logging. As soon as the method that does the audit logging is complete, the transaction is committed, and the credit card payment transaction continues on it's way.