Transactional Capabilities
in Oracle9iAS Containers for J2EE (OC4J)
Date: 22-Jul-2002
Introduction
A key service required for robust server side development
is transactions. A Transaction can be defined as a series of operations that
appear to execute as one large, atomic operation. Transactions guarantee an
all-or-nothing value proposition. Transactions allows multiple users to share
the same data and guarantee that any set of updated data will be completely
updated, with no interleaving of updates from other clients. This document contains
the following topics:
XML deployment descriptors are used to specify transaction
boundaries for components, in case of declarative transactions. At runtime,
the container initiates a transaction and commits it. This helps the user in
avoiding the transaction related code and helps in focussing on the core business
logic of the application. In this approach, the EJB code is completely isolated
from the transaction APIs. For sample deployment descriptor code snippet click
here.
In this approach, the transactions have to be controlled by
the bean developer explicitly. The benefit of this approach is that the bean
developer has full control over the transactional boundaries. The developer
has to start a transaction by issuing begin and complete the transaction by
issuing a end or abort statement. For sample code snippet click here.
Transactional Attributes
For an EJB that uses Container managed transaction, the transaction
can be controlled through various attributes called Transactional attributes.
These attributes are different for various EJBs. This is mentioned in the EJB
deployment descriptor. The various transactional attributes available are Required,
NotSupported, RequiresNew, Supports, Mandatory or Never. For sample code which
specifies transactional attribute please click here.
Required
- A bean with this transaction attribute will always run in a transaction.
If there is an available transaction, the bean joins the existing transaction.
If a transaction is not available, the EJB container starts a new transaction.
RequiresNew - A bean with this transaction attribute
will always run in a new transaction. If there is an available transaction,
then the transaction is suspended. After the completion of the new created
transaction, the container resumes the old transaction which was suspended
earlier.
Supports
- A bean with this transaction attribute will run in a transaction if the
transaction had been initiated by the client.
Mandatory - A bean
with this transaction attribute runs in a existing transaction. javax.ejb.TransactionRequiredException
is thrown back to the caller if there is no available transaction. This is
to ensure that the bean will always run in a transaction.
NotSupported - A bean with this transaction attribute cannot
be involved in a transaction. If the client calling the bean has initiated
a transaction, then the transaction is suspended temporarily till the bean
method is invoked. Later the transaction is resumed.
Never - A bean with this transaction attribute cannot be involved in a transaction.
If the client calling the bean has initiated a transaction, then the container
throws an exception to the client.
Transaction Isolation
Isolation protects concurrently executing transactions from viewing each
other's incomplete results. This can be achieved by using locks on the database,
which prevents multiple components accessing same data simultaneously. Isolation
level can be specified in the deployment descriptor XML file. If very strict
isolation is specified, then each concurrent transaction will be isolated
from all other transactions at the expense of performance. On the other hand,
specifying a very loose isolation will result in transactions not being isolated
but also guarantees a very high performance. There are four transaction isolation
levels defined in EJB specification.
READ_UNCOMMITTED
Doesn't offer any isolation but guarantees high performance
READ_COMMITTED
Solves dirty read problem
REPEATABLE_READ
Solves both dirty read as well as unrepeatable read
problems
SERIALIZABLE
Solves dirty read, unrepeatable reand and phantom problems
Above four levels of isolation depends on the isolation level supported
by the underlying data-source.
Dirty read occurs when an application reads the data that has been updated
but not committed to database.
Unrepeatable read problem occurs when a component finds that
the data it read previously has been modified by some other component. Phantom
problems are related to appearance of a new set of data in a database between
2 database operations
These different isolation levels are set in the XML deployment
descriptor e orion-ejb-jar.xml, which has to be packaged with deployment jar
file. The tag <entity-deployment> should be present for every entity bean.
The isolation attribute value can be set using the isolation attribute.
DTD for this file can be found at orion-ejb-jar.dtd.
For Sample orion-ejb-jar.xml file please click here.
Concurrency Control
There are 2 ways by which concurrency control can be implemented.
They are pessimistic & optimistic. In optimistic concurrency control,
lock is acquired only at the time of committing the transaction, whereas in
pessimistic concurrency control, lock is acquired for the entire duration of
the transaction. Concurrency control can be specified in <entity-deployment>
tag of orion-ejb-jar.xml.
Bookmark