|
|
[an error occurred while processing this directive]
|
|
|
 |
a practical primer |
|
|
|
What are Container-Managed Transactions?
As a developer, you no doubt have already come across a business solution that required the type of high-level data security and robustness that only transactions can provide. Transactions aren't new; their use to protect vital data from corruption and inappropriate changes has been discussed ad nauseam since the first accountant etched his ledger balance in stone. (Well, maybe not that long ago; but at least since the dawning of the Computer Age.)
The topic of Enterprise Java Beans (EJB), however, is relatively new. With all of the major application servers supporting J2EE technology, developers everywhere are finding themselves knee-deep in EJB decisions. This article outlines the concept of container-managed transactions (CMT), one of three EJB transaction choices. (The other choices are bean-managed transactions (BMT) and client-managed transactions.)
With CMT, the EJB container handles the transaction for you, eliminating many of the headaches associated with implementation. You simply define certain transaction attributes at the time of application assembly or deployment, and the container does the rest.
Here's what you need to know.
When can I use them?
Sun's Enterprise Java Bean Specification 1.1 states that an entity bean must use CMT. Session beans use either CMT or BMT, but not both. The other choice for session beans is no transaction at all.
What do they do for me?
With CMT, you must determine which transaction attribute value applies to each available entity bean method. Once that determination is made, you need only make the appropriate entry into the deployment descriptor and deploy the transaction. The container then handles all begin, commit and rollback activities involved with managing the transaction. The container provider will have built and tested the appropriate transaction behaviors. Good application servers will provide capable transaction support and offer performance benefits, such as data caching, which can significantly reduce the number SQL calls to the database.
|
|
|
what aspects of CMT are portable? |
|
|
|
J2EE specification offers standardization
The decision to use a J2EE application server is more often than not based on the desire to have application portability. Once an application is developed, organizations want the flexibility of running it on any J2EE application server. CMT, as they are defined under the umbrella of Sun's EJB specification, provide the maximum likelihood that an organization's transaction behavior definitions will offer such portability.
Transactions types
Transactions are demarcated around methods. These are defined in the deployed descriptor using a syntax following the EJB DTD found in the Sun EJB specification. Example XML code for a CMT may look like this:
<?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>AddUTyped</ejb-name>
<home>com.mike.SBAddUTyped.AddUTypedHome</home>
<remote>com.mike.SBAddUTyped.SBAddUTyped</remote>
<ejb-class>com.mike.SBAddUTyped.SBAddUTypedBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<description>Transactions required for this method.</description>
<method>
<ejb-name>AddUTyped</ejb-name>
<method-name>prependUTyped</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
Visual tools are often available to simplify CMT definition. Figure 1 shows one such user interface tool.
Figure 1-- SilverStream Jar Designer Transaction Attribute Definition
Transaction attributes
Sun's EJB specification describes six different transaction attribute values. These define the transaction behaviors that the container should take for the methods marked with these attributes. As a method marked with each is called, three essential behaviors may take place:
- The container needs to do nothing in regard to the current transaction state;
- The container needs to start a new transaction;
- The container throws an exception to warn of an invalid transaction state for the method.
Table 1 -- CMT Transaction Attribute Values
| Not Supported | If a method with this attribute value is called from within a transaction context, the transaction is suspended while the method is executed. |
| Required | A method with this transaction attribute value must be executed from within a transaction context. If not already within a transaction context, a new transaction will be started. |
| RequiresNew | A method with this transaction attribute value must be executed from within a new transaction context. If not already within a context, a new one is started. If a context already exists, it is suspended and a new one is started. |
| Supports | A method with this transaction attribute value executes with a transaction context if one exists. If one does not, it will execute without a transaction context. |
| Mandatory | A method with this transaction attribute value must execute within an already present transaction context. If one does not exist a javax.transaction.TransactionRequiredException will be thrown by the container. |
| Never | A method with this transaction attribute value must always execute outside the context of a transaction. If a transaction exists when it is called a java.rmi.Remote-Exception will be thrown by the container. |
Methods available with CMT
There are only a couple of transaction-related methods available for use under CMT. These are:
javax.ejb.EJBContext.setRollbackOnly()
javax.ejb.EJBContext.getRollbackOnly()
In a nutshell, setRollbackOnly()tells the container that it can not commit the transaction. When the time is right, roll it back.
getRollbackOnly() checks to see the if it has been marked for rollback. These methods can only be called from methods marked with attribute values of Required, RequiresNew, or Mandatory. Calling from methods marked otherwise will result in the container throwing a java.lang.IllegalStateException.
It should be noted that beans marked for CMT cannot call EJBContext.getUserTransaction(). Doing so will result in a java.lang.IllegalStateException to be thrown by the container.
The Session Synchronization Interface
javax.ejb.SessionSynchronization is an optional interface available to stateful session beans. Similar to the set/getRollbackOnly methods mentioned above, a bean implementing this interface must use methods that only use Required, RequiresNew, or Mandatory transaction attribute values. When implemented, this results in three transaction callbacks that take place: afterBegin(), beforeCompletion(), and afterCompletion().
The afterBegin() method is called by the container before the first business method in a transaction. beforeCompletion() is called after completion of the work of the transaction, but before committing the resource managers. Very often, calls to setRollbackOnly() are made here. afterCompletion() is called when the transaction is complete.
|
|
|
is CMT good enough? |
|
|
|
|
Unlike some other container-managed EJB technologies, CMT has been well received. BMT, the counterpart to CMT, offer the flexibility of demarcation control, but at the expense of portability, proven and tested transaction management, and predictability. While necessity sometimes drives the need for demarcation that extends beyond the scope of CMT, bean builders typically choose CMT over BMT.
|
|
|
summary |
|
|
|
|
EJB container-managed transactions have greatly simplified the building of robust, predictable and portable distributed-data applications. CMT provide the benefits of a widely accepted, standards-based architecture, which is clearly defined by Sun's EJB specification. The use of CMT can give you an adequate level of transaction control, while shielding you from distracting minutiae. This freedom can enhance your ability to serve the problem domain by allowing you to focus your energy on building real business solutions, rather than constructing technical bridges to lands unknown.
|
|
|
|
|
|
A Practical Primer
