Choose the most appropriate transaction management scheme.
Choosing among the Different Management Schemes using EJB
Which form of transaction management is best?
This is a design issue and is often subjective. However, there are situations where one transaction method is preferable, or even necessary.
Client-managed transactions
When the client is not an EJB, but a regular program, it is best if it does not manage transactions. It should delegate the responsibility of managing the transaction to the EJB or the EJB's container.
The reasons for this are:
The client programmer does not usually know anything about the EJB except its interface.
The client programmer is unlikely to understand the ramifications of managing the EJBs transaction themselves as they usually do not know the internals of the EJB and its transaction requirements.
The client programmer will require access to the transaction service. Most client programs are written for environments that do not have access to the transaction service such as web browsers or Visual Basic programs.
Container-managed transactions
These are very convenient. They are specified declaratively in the deployment descriptor. The programmer does little work. They are propagated automatically to downstream beans or transactional resources. However, there are problems.
The problems with container-managed transactions
There is one problem with the scenario above. Imagine that both the credit() and the debit() methods were declared as "REQUIRED."
This means that there would be a begin and a commit for a single credit() and the same for the debit().
What would happen if you wanted to do a transfer? It would not work.
The solution is to create a second bean as follows:
The transfer() method in the Transfer bean will be declared "REQUIRED. "credit() and debit() will now run under a single transaction started and committed within the Transfer bean and propagated to the BankAccount bean.
Bean-managed transactions
Bean-managed transactions are valid if all of the following conditions are true:
The bean either must be a client to multiple beans or write to multiple transactional resources.
You must have step-by-step control over the transaction within the bean.
The transaction must cross multiple methods. If all the conditions are met, then you can use this management scheme.