ejb transactions

EJB Transactions

EJB transactions are a set of concepts and a set of mechanisms that attempt to insure the integrity and consistency of a database for which multiple clients may attempt to access it and/or update it simultaneously.

The reader is expected to understand the rationale for and basic principles involved in transactions. Here, the discussion will focus on second-level concepts, such as the various types of transaction included in the Java Transaction Service specification, and on specific mechanisms for specifying the transaction properties for EJB classes and methods.

ACID

Basic properties of transactions can be summarized using the ACID mnemonic:

Atomic All or nothing. If a transaction is interrupted, all previous steps within that transaction are undone.

Consistent The state of objects and/or the state of tables within a database move from one consistent state to another consistent state.

Isolated What happens within one transaction should not affect or be visible within another transaction

Durable The effects of a transaction are persistent.

Transaction Attributes

Transactions can be defined at several different levels and in several different ways.

Levels. With respect to levels, transaction attributes may be defined at the level of EJB (or class), method within class, or segment of code within method. The more specific specification take precedence over the specification for the containing segment. Thus, attributes specified for a particular method take precedence over the specification for an entire EJB.

Specification. With respect to specification, transaction attributes may be specified through deployment descriptors or through Java code embedded in a class. Unless the programmer is skilled in working with transaction and unless there is a compelling reason to do so, a best practices approach for most applications will be to specify transactions declaratively -- through deployment descriptors attached to EJB classes that enable the EJB Container to generate and handle transactions. Declarative transactions attributes can be set at the time of development, through VisualAge, and/or at the time of deployment (or thereafter), through the WebSphere Administrative Console. In both cases, attributes can be set for the bean as a whole, for individual methods, or both.

The EJB 1.0 Specification includes six defined transaction attributes:

TX_REQUIRED Methods executed within a transaction. If client provides transaction, it is used; if not, new transaction generated. Commit at end of method. Default attribute set by VisualAge.
Well-suited for EJB Sessions.

TX_MANDATORY Client of this EJB must create a transaction in which this method operates, otherwise an error.
Well-suited for EJB Entitys.

TX_REQUIRES_NEW Methods executed within a transaction. If client provides transaction, it is suspended. A new transaction is generated, regardless. Commit at end of method.

TX_SUPPORTS Transactions optional.

TX_NOT_SUPPORTED Transactions not supported; if provided, ignored..

TX_BEAN_MANAGED Code in the EJB responsible for explicit transaction control. Applicable in WebSphere to EJB Sessions only.

Consider: what aspects of the ACID mnemonic are covered/not covered by transaction attributes?

Isolation Levels

Isolation levels provide a degree of control of the effects one transaction can have on another. Since concurrent effects are determined by the precise ways a DBMS handles locks, and databases and their drivers handle these locks differently, the semantics of isolation mechanisms based on them are not well-defined. Nevertheless, certain defined or approximate properties can be specified.

TRANSACTION_SERIALIZABLE Strongest level of isolation. All rows locked for duration of transaction. Can produce deadlocks! (But not if Find for Update set to false.)

TRANSACTION_REPEATABLE_READ Transaction always reads same data during transaction. Phantom records possible. Default level of isolation set by VisualAge. Usually suitable for all but most critical operations.

TRANSACTION_READ_COMMITTED Can't read uncommitted data by another transaction, but nonrepeatable reads and phantom records possible.

TRANSACTION_READ_UNCOMMITTED Can read uncommitted data by another transaction, and nonrepeatable reads and phantom records possible.

Caching

To provide fine-tuning for efficiency, VisualAge and WebSphere support two caching strategies.

Shared Presumes multiple EJBs can access a particular table (hence, shared access); therefore, data is read from the database into the bean at the beginning of each transaction. Default caching option set by VisualAge.

Exclusive Presumes only a single EJB can access a particular table (hence, exclusive access); therefore, cached data is maintained in the bean between transactions

Atomic	All or nothing. If a transaction is interrupted, all previous steps within that transaction are undone.
Consistent	The state of objects and/or the state of tables within a database move from one consistent state to another consistent state.
Isolated	What happens within one transaction should not affect or be visible within another transaction
Durable	The effects of a transaction are persistent.

TX_REQUIRED	Methods executed within a transaction. If client provides transaction, it is used; if not, new transaction generated. Commit at end of method. Default attribute set by VisualAge. Well-suited for EJB Sessions.
TX_MANDATORY	Client of this EJB must create a transaction in which this method operates, otherwise an error. Well-suited for EJB Entitys.
TX_REQUIRES_NEW	Methods executed within a transaction. If client provides transaction, it is suspended. A new transaction is generated, regardless. Commit at end of method.
TX_SUPPORTS	Transactions optional.
TX_NOT_SUPPORTED	Transactions not supported; if provided, ignored..
TX_BEAN_MANAGED	Code in the EJB responsible for explicit transaction control. Applicable in WebSphere to EJB Sessions only.

TRANSACTION_SERIALIZABLE	Strongest level of isolation. All rows locked for duration of transaction. Can produce deadlocks! (But not if Find for Update set to false.)
TRANSACTION_REPEATABLE_READ	Transaction always reads same data during transaction. Phantom records possible. Default level of isolation set by VisualAge. Usually suitable for all but most critical operations.
TRANSACTION_READ_COMMITTED	Can't read uncommitted data by another transaction, but nonrepeatable reads and phantom records possible.
TRANSACTION_READ_UNCOMMITTED	Can read uncommitted data by another transaction, and nonrepeatable reads and phantom records possible.

Shared	Presumes multiple EJBs can access a particular table (hence, shared access); therefore, data is read from the database into the bean at the beginning of each transaction. Default caching option set by VisualAge.
Exclusive	Presumes only a single EJB can access a particular table (hence, exclusive access); therefore, cached data is maintained in the bean between transactions