which is the correct set of transaction attributes for the methods in the session beans?

A developer implements a system in which transfers of goods are monitored. Each transfer needs
a unique ID for tracking purposes. The unique ID is generated by an existing system which is also
used by other applications. For performance reasons, the transaction that gets the unique ID
should be as short as possible. The scenario is implemented in four steps which are implemented
in four business methods in a CMT session bean:

These methods are called by the addTransfer method of a second CMT session bean in the
following order:
checkGooods, getUniqueId, checkAmount, storeTranfer
Assuming no other transaction-related metadata, which is the correct set of transaction attributes
for the methods in the session beans?

A.
0.addTransferREQUIRED
1.checkGoodsREQUIRED
2.getUnigueIdREQUIRES_NEW
3.checkAmountsNOT_SUPPORTED
4.storeTransferMANDATORY

B.
0.addTransferREQUIRED
1.checkGoodsREQUIRED
2.getUnigueIdREQUIRED
3.checkAmountsREQUIRED
4.storeTransferREQUIRED

C.
0.addTransferREQUIRED
1.checkGoodsREQUIRED
2.getUnigueIdREQUIRES_NEW
3.checkAmountsNEVER
4.storeTransferMANDATORY

D.
0.addTransferNOT_SUPPORTED
1.checkGoodsREQUIRED
2.getUnigueIdREQUIRES_NEW
3.checkAmountsNOT_SUPPORTED
4.storeTransferMANDATORY

Explanation:
Step 2: Must start a new transaction. use REQUIRES_NEW
Step 3: No need for this step: use Not Supported
Use the NotSupported attribute for methods that dont need transactions. Because transactions
involve overhead, this attribute may improve performance.
Step 4: Use Mandatory:
Use the Mandatory attribute if the enterprise beans method must use the transaction of the client.
Note:
*In an enterprise bean with container-managed transaction(CMT)demarcation, the EJB container
sets the boundaries of the transactions. You can use container-managed transactions with any
type of enterprise bean: session, or message-driven. Container-managed transactions simplify
development because the enterprise bean code does not explicitly mark the transactions
boundaries. The code does not include statements that begin and end the transaction.
*A transaction attribute can have one of the following values:

Required
RequiresNew
Mandatory
NotSupported
Supports
Never
*Required Attribute
If the client is running within a transaction and invokes the enterprise beans method, the method
executes within the clients transaction. If the client is not associated with a transaction, the
container starts a new transaction before running the method.
The Required attribute is the implicit transaction attribute for all enterprise bean methods running
with container-managed transaction demarcation. You typically do not set the Required attribute
unless you need to override another transaction attribute. Because transaction attributes are
declarative, you can easily change them later.
*RequiresNew Attribute
If the client is running within a transaction and invokes the enterprise beans method, the container
takes the following steps:
Suspends the clients transaction
Starts a new transaction
Delegates the call to the method
Resumes the clients transaction after the method completes
If the client is not associated with a transaction, the container starts a new transaction before
running the method.
You should use the RequiresNew attribute when you want to ensure that the method always runs
within a new transaction.
*Mandatory Attribute

If the client is running within a transaction and invokes the enterprise beans method, the method
executes within the clients transaction. If the client is not associated with a transaction, the
container throws the TransactionRequiredException.
Use the Mandatory attribute if the enterprise beans method must use the transaction of the client.
*NotSupported Attribute
If the client is running within a transaction and invokes the enterprise beans method, the container
suspends the clients transaction before invoking the method. After the method has completed, the
container resumes the clients transaction.
If the client is not associated with a transaction, the container does not start a new transaction
before running the method.
Use the NotSupported attribute for methods that dont need transactions. Because transactions
involve overhead, this attribute may improve performance.
Reference:The Java EE 5 Tutorial,Container-Managed Transactions