Java Reference
In-Depth Information
The
REQUIRES_NEW
attribute is of limited use in most applications. It should be used in
situations where you need a transaction but don't want a transaction rollback to affect a
client and vice versa. Logging is a great example of where this transaction attribute could
be used. Even if the parent transaction rolls back, you still want the log message recorded.
On the flip side, if creating the logging message fails, you don't want the operation it was
logging to also fail.
SUPPORTS
The
SUPPORTS
attribute means that the method is ambivalent to the presence of a trans-
action. If a transaction has been started, the method will join the existing transaction. If
no transaction has been started, then the method will execute without a transaction. The
SUPPORTS
attribute is typically useful for methods that perform read-only operations such
as retrieving a record from a database table. In the snag-it example, the method for check-
ing whether a method has a bid is annotated with
SUPPORTS
because it modifies no data.
MANDATORY
MANDATORY
means that the method requires an existing transaction to already be in pro-
gress for this method to join. We briefly alluded to this when we talked about the
Cred-
itCardManager
bean. When the container goes to invoke the method, it'll check to
make sure that a transaction is already in progress. If a transaction hasn't previously
been started, an
EJBTransactionRequiredException
will be thrown. Thus, in the
CreditCardManager
bean, if the method is invoked without a transaction, an excep-
tion will be thrown.
NOT_SUPPORTED
When assigning
NOT_SUPPORTED
as the transaction attribute, the EJB method can't be
invoked in a transactional context. If a caller with an associated transaction invokes the
method, the container will suspend the transaction, invoke the method, and then resume
the transaction when the method returns. This attribute is typically only useful for an MDB
supporting a JMS provider in nontransactional, auto-acknowledge mode. In this case, the
message is acknowledged as soon as it's successfully delivered and the MDB has no cap-
ability or apparent need to support rolling back message delivery.
