This chapter is from the book
This chapter is from the book
This chapter is from the book
Transactions
Transactions play an important role in most application development projects. This is not different when developing an EJB-based solution. Transactions can be complex features to implement, but EJB-based systems require that the vendors implement transaction processing within the container. This does not mean, however, that you do not have to be concerned about transactions.
Simply put, a transaction is a grouping of work that represents a single unit or task. This single unit may contain something as simple as one step or many complex steps to be treated as one. Many times, people ask "Why do I need transactions?" Transactions help to alleviate the complexity of coordinating data or resource access across many clients.
Whenever you use transactions, you need to understand the four main characters: Atomicity, Consistency, Isolation, and Durability, commonly referred to as ACID. These four properties and the basic requirements fulfilled through the use of transactions are shown in Table 23.7.
Table 23.7 Properties of a Successful Transaction
|
Property |
Description |
|
Atomicity |
All or none of a transaction's effects are kept. |
|
Consistency |
Transactions preserve data integrity and consistency. |
|
Isolation |
Intermediate results of a transaction are not visible outside that transaction. |
|
Durability |
Committed effects survive system failures. |
Transaction Attributes
With declarative demarcation you specify to the container which methods are going to be included within transactional processing. Each method is given a transactional context that it uses to participate within the given transaction. Enterprise JavaBeans define seven different types of transaction attributes, each having a slightly different implementation, as shown in Table 23.8.
Table 23.8 Transaction Attributes Available for EJB Transactional Implementation
|
Transactional Attribute |
Description |
|
Required |
Guarantees that the work performed by the method is within a global transaction context. If the caller already has a transaction context, the container uses the same context. If the caller has not been assigned a transaction context, the container begins a new transaction automatically. The attribute makes it easy to implement multiple beans and coordinate the work of all the beans using the same global transaction for all the beans within the same transaction. |
|
RequiresNew |
The container invokes the enterprise bean method with a new transaction it has started with. The container ends this transaction when the invocation completes. The transaction is ended either by a rollback or commit request. |
|
Mandatory |
This allows bean methods to declare that they must be invoked by clients within transactions. Typically, such bean methods are not intended to be used on their own but are expected to be one part of a larger transaction. |
|
Supports |
The beans participate in interactions without causing new transactions to be started, yet using them if they are present. Only application logic that can function correctly both within a transaction and without one should be allowed to use this mode. |
|
NotSupported |
Allows bean methods with implementations that can't or shouldn't be invoked with a transaction. This might happen, for instance, if a bean does not want the client's transaction to propagate to resources that it may contact during its processing. |
|
Never |
This allows a bean method to declare that it must never be invoked by clients running transactions. Typically, this is because the bean's method performs some activity that can provide ACID properties. This attribute has been deprecated in EJB 2.0 specifications. |
|
Bean-managed |
This is also known as programmatic transactional control. In other words, the transactions are implemented within the source of the bean. |
Transaction Usage
Transaction usage within the container is specified within the deployment descriptor. JBuilder's EJB Designer provides an easy-to-use interface that gives access to the transactional attributes. This interface makes it simple to define a transactional context that will ultimately be contained within the deployment descriptor. For example, let's look at our Employee entity bean again. The following process is used to define the transactional context for the entity bean:
-
Select a bean to define a transaction attribute.
-
Underneath the Employee entity you will see a child node entitled Container Transaction.
-
Double-click on the Container Transaction; this loads the Container Transaction editor, shown in Figure 23.15.
-
Using the drop-down combo boxes, select the interface—either Home, Remote, LocalHome, or Local. After you select an interface, you are then allowed to either select all the methods (*) or specify a method.
-
Finally, select the appropriate transactional attribute.
)
Figure
23.15 Define a transaction attribute using the Container Transaction editor.
The results of this process are placed in the deployment descriptor, as shown in Listing 23.19.
Listing 23.19 Portion of the Deployment Descriptor Containing the Transaction Attributes
<container-transaction>
<method>
<description />
<ejb-name>Employee</ejb-name>
<method-intf>LocalHome</method-intf>
<method-name>create</method-name>
<method-params>
<method-param>java.lang.Short</method-param>
</method-params>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<description />
<ejb-name>Employee</ejb-name>
<method-intf>LocalHome</method-intf>
<method-name>findAll</method-name>
<method-params />
</method>
<trans-attribute>Supports</trans-attribute>
</container-transaction>