Checks if a transaction is an existing transaction.
Checks if a transaction is an existing transaction.
the transaction manager
boolean
Checks if current transaction is set to rollback only.
Checks if current transaction is set to rollback only.
the transaction manager
boolean
Wraps body in a transaction with MANDATORY semantics.
Wraps body in a transaction with MANDATORY semantics.
Throws a TransactionRequiredException if there is no transaction active in scope.
Wraps body in a transaction with NEVER semantics.
Wraps body in a transaction with NEVER semantics.
Throws a SystemException in case of an existing transaction in scope.
Wraps body in a transaction with NOT_SUPPORTED semantics.
Wraps body in a transaction with NOT_SUPPORTED semantics.
Suspends existing transaction, invokes body, resumes transaction.
Wraps body in a transaction with REQUIRED semantics.
Wraps body in a transaction with REQUIRED semantics.
Creates a new transaction if no transaction is active in scope, else joins the outer transaction.
Wraps body in a transaction with REQUIRES_NEW semantics.
Wraps body in a transaction with REQUIRES_NEW semantics.
Suspends existing transaction, starts a new transaction, invokes body, commits or rollbacks new transaction, finally resumes previous transaction.
Wraps body in a transaction with SUPPORTS semantics.
Wraps body in a transaction with SUPPORTS semantics.
Basicalla a No-op.
Trait that implements a JTA transaction service that obeys the transaction semantics defined in the transaction attribute types for the transacted methods according to the EJB 3 draft specification. The aspect handles UserTransaction, TransactionManager instance variable injection thru @javax.ejb.Inject (name subject to change as per EJB 3 spec) and method transaction levels thru @javax.ejb.TransactionAttribute.
This trait should be inherited to implement the getTransactionManager() method that should return a concrete javax.transaction.TransactionManager implementation (from JNDI lookup etc).
Transaction attribute semantics
(From http://www.kevinboone.com/ejb-transactions.html)
Required
'Required' is probably the best choice (at least initially) for an EJB method that will need to be transactional. In this case, if the method's caller is already part of a transaction, then the EJB method does not create a new transaction, but continues in the same transaction as its caller. If the caller is not in a transaction, then a new transaction is created for the EJB method. If something happens in the EJB that means that a rollback is required, then the extent of the rollback will include everything done in the EJB method, whatever the condition of the caller. If the caller was in a transaction, then everything done by the caller will be rolled back as well. Thus the 'required' attribute ensures that any work done by the EJB will be rolled back if necessary, and if the caller requires a rollback that too will be rolled back.
RequiresNew
'RequiresNew' will be appropriate if you want to ensure that the EJB method is rolled back if necessary, but you don't want the rollback to propogate back to the caller. This attribute results in the creation of a new transaction for the method, regardless of the transactional state of the caller. If the caller was operating in a transaction, then its transaction is suspended until the EJB method completes. Because a new transaction is always created, there may be a slight performance penalty if this attribute is over-used.
Mandatory
With the 'mandatory' attribute, the EJB method will not even start unless its caller is in a transaction. It will throw a
TransactionRequiredExceptioninstead. If the method does start, then it will become part of the transaction of the caller. So if the EJB method signals a failure, the caller will be rolled back as well as the EJB.Supports
With this attribute, the EJB method does not care about the transactional context of its caller. If the caller is part of a transaction, then the EJB method will be part of the same transaction. If the EJB method fails, the transaction will roll back. If the caller is not part of a transaction, then the EJB method will still operate, but a failure will not cause anything to roll back. 'Supports' is probably the attribute that leads to the fastest method call (as there is no transactional overhead), but it can lead to unpredicatable results. If you want a method to be isolated from transactions, that is, to have no effect on the transaction of its caller, then use 'NotSupported' instead.
NotSupported
With the 'NotSupported' attribute, the EJB method will never take part in a transaction. If the caller is part of a transaction, then the caller's transaction is suspended. If the EJB method fails, there will be no effect on the caller's transaction, and no rollback will occur. Use this method if you want to ensure that the EJB method will not cause a rollback in its caller. This is appropriate if, for example, the method does something non-essential, such as logging a message. It would not be helpful if the failure of this operation caused a transaction rollback.
Never
The 'NotSupported attribute will ensure that the EJB method is never called by a transactional caller. Any attempt to do so will result in a
RemoteExceptionbeing thrown. This attribute is probably less useful thanNotSupported', in that NotSupported will assure that the caller's transaction is never affected by the EJB method (just asNever' does), but will allow a call from a transactional caller if necessary.