|
|
[an error occurred while processing this directive]
|
|
|
 |
the role of Bean-Managed transactions |
|
|
|
When building an application with Enterprise Java Beans (EJB), you may sometimes want more transaction control than Container-Managed Transactions (CMT) allow. The EJB 1.1 specification addresses this need with Bean-Managed Transactions (BMT).
Under the EJB 1.1 specification, BMT are only available for session beans. (Under 1.0, they were also available for entity beans.) With BMT, you can programmatically demarcate a transaction within your EJB business methods. This ability to mark the confines of transactions with begin(), rollback(), and commit() method calls provides great flexibility. However, it's an all-or-nothing decision. Beans cannot use both BMT and CMT, so you must decide what type of transaction management you wish to use before you begin programming.
|
|
|
BMT basics |
|
|
|
|
Using BMT is relatively easy. From within the session bean's business method, get an instance of a class that implements the javax.transaction.UserTransaction interface from the EJB context. Then, simply call UserTransaction.begin() to mark the beginning of the transaction, and UserTransaction.rollback() or UserTransaction.commit() to rollback or commit the transaction.
|
|
|
getting a UserTransaction |
|
|
|
The EJB 1.1 specification requires the container to support the javax.transaction.UserTransaction interface. An object instance of a class that implements this interface can be obtained from the EJB context with the EJBContext.getUserTransaction() method:
UserTransaction utx = m_context.getUserTransaction();
|
|
|
demarcating the transaction |
|
|
|
Once you have an instance of javax.transaction.UserTransaction, mark the beginning of the transaction with the begin() method:
utx.begin();
The business method will now do some work. When finished, it will either call commit() to commit the transaction or rollback() to roll it back. Pretty simple. However, note that with stateless session beans the transaction must be committed or rolled back before the method returns. (See Example 1.) If this is not done, the container will do four things: 1) log an application error, 2) roll back the transaction, 3) discard the session bean instance, and 4) throw a java.rmi.RemoteException to the client. With stateful session beans, a transaction can be started in one business method and committed or rolled back in another. (See Example 2.)
Example 1 - Bean-Managed Transaction that Begins and Ends in the Same Method
void myMethod()
{
// get the UserTranaction from the EJB context
javax.transaction.UserTransaction utx = m_context.getUserTransaction();
// start the transaction
utx.begin();
do some work...
if (EVERYTHINGS_OK)
{
// commit the transaction
utx.commit();
}
else
{
// roll it back
utx.rollback();
}
}
Because stateful session beans maintain a conversational state across method calls with the client, it is not necessary to commit or roll back transactions within the same method that the begin() method was called. The container will maintain the transaction context association with the session bean instance.
Example 2 - Bean-Managed Transaction that Begins and Ends in Different Methods (Stateful Session Beans Only)
void myMethod1()
{
// get the UserTranaction from the EJB context
javax.transaction.UserTransaction utx = m_context.getUserTransaction();
// start the transaction
utx.begin();
do some work...
}
void myMethod2()
{
// get the UserTranaction from the EJB context
javax.transaction.UserTransaction utx = m_context.getUserTransaction();
do some more work...
if (EVERYTHINGS_OK)
{
// commit the transaction
utx.commit();
}
else
{
// roll it back
utx.rollback();
}
}
|
|
|
Assembly and Deployment Time |
|
|
|
With BMT, there is little to do at assembly time other than mark the bean so that the container knows it uses bean-managed transactions. If you are manually building your own deployment descriptor, this can be accomplished by using <transaction-type> tags in your deployment descriptor. (See Example 3.)
Example 3 - Deployment Description for a Bean-Managed Transaction
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN"
"http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>SBTransaction</ejb-name>
<home>com.mike.BMT.SBTransactionHome</home>
<remote>com.mike.BMT.SBTransaction</remote>
<ejb-class>com.mike.BMT.SBTransactionBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Bean</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
</assembly-descriptor>
</ejb-jar>
Application servers often provide graphical tools to assist in building deployment descriptors. (See Figure 1.)
Figure 1 - SilverStream Graphical Deployment Descriptor Editing Tool
While EJB deployment specifics often vary according to application server type, there are generally few, if any, specific deployment requirements for BMT.
|
|
|
summary |
|
|
|
|
BMT are powerful, simple to use tools that offer a high degree of freedom in demarcating transactions in EJB session beans. Through the use of the javax.transaction.UserTransaction interface and the begin(), commit(), and rollback() methods, you can easily mark the boundaries of transactions and enable units of work to be performed atomically.
|
|
|
|
|
|
The Role of Bean-Managed Transactions
