|
Oracle TopLink Developer's Guide
10g Release 3 (10.1.3) B13593-01 |
|
 Previous |
 Next |
|
Oracle TopLink Developer's Guide
10g Release 3 (10.1.3) B13593-01 |
|
|
Previous |
Next |
A database transaction is a set of operations (create, read, update, or delete) that either succeed or fail as a single operation. The database discards, or rolls back, unsuccessful transactions, leaving the database in its original state. Transactions may be internal (that is, provided by TopLink) or external (that is, provided by a source external to the application, such as an application server).
In TopLink, transactions are contained in the unit of work object. You acquire a unit of work from a session (see "Acquiring a Unit of Work") and using its API, you can control transactions directly or through a Java 2 Enterprise Edition (J2EE) application server transaction controller such as the Java Transaction API (JTA).
Transactions execute in their own context, or logical space, isolated from other transactions and database operations.
The transaction context is demarcated; that is, it has a defined structure that includes:
A begin point, where the operations within the transaction begin. At this point, the transaction begins to execute its operations.
A commit point, where the operations are complete and the transaction attempts to formalize changes on the database.
The degree to which concurrent (parallel) transactions on the same data are allowed to interact is determined by the level of transaction isolation configured. ANSI/SQL defines four levels of database transaction isolation as shown in Table 100-1. Each offers a trade-off between performance and resistance from the following unwanted actions:
Dirty read: a transaction reads uncommitted data written by a concurrent transaction.
Nonrepeatable read: a transaction rereads data and finds it has been modified by some other transaction that was committed after the initial read operation.
Phantom read: a transaction reexecutes a query and the returned data has changed due to some other transaction that was committed after the initial read operation.
Table 100-1 Transaction Isolation Levels
| Transaction Isolation Level | Dirty Read | Nonrepeatable Read | Phantom Read |
|---|---|---|---|
|
Read Uncommitted |
Yes |
Yes |
Yes |
|
Read Committed |
No |
Yes |
Yes |
|
Repeatable Read |
No |
No |
Yes |
|
Serializable |
No |
No |
No |
As a transaction is committed, the database maintains a log of all changes to the data. If all operations in the transaction succeed, the database allows the changes; if any part of the transaction fails, the database uses the log to roll back the changes.
Like any transaction, a unit of work transaction provides the following:
Unit of work operations occur within a unit of work context, in which writes are isolated from the database until commit time. The unit of work executes changes on copies, or clones, of objects in its own internal cache, and if successful, applies changes to objects in the database and the session cache.
In a standalone TopLink application, your application demarcates transactions using the unit of work.
If your application includes a J2EE container that provides container-managed transactions, your application server demarcates transactions using its own transaction service. You configure TopLink to integrate with the container's transaction service by specifying a TopLink external transaction controller.
A TopLink external transaction controller class integrates the unit of work with an application server's transaction service. Using an external transaction controller, your application can participate in transactions that span multiple data sources and that are managed by the application server. The external transaction controller coordinates messages and callbacks between the application server's transaction service and the unit of work.
When you configure your application to use an external transaction controller (see "Configuring the Server Platform"), the unit of work executes as part of an external transaction. The unit of work still manages its own internal operations, but it waits for the external transaction to tell it to write changes back to the database and to the session cache.
Note that because the transaction happens outside of the unit of work context and is controlled by the application server's transaction service, errors can be more difficult to diagnose and fix because exceptions may occur outside of your application code, for example, during application server initiated call-backs.
You can integrate the unit of work with the following:
The Java Transaction API (JTA) is the application programming interface you use to interact with a transaction manger.
Using JTA, your application can participate in a distributed transaction. A transaction manager that implements JTA provides transaction management and connection pooling and enables your application to interact with multiple data sources transparently by using JTA.
For more information, see "Integrating the Unit of Work With an External Transaction Service".
The CORBA Object Transaction Service (OTS) specification is part of the Common Object Request Brokers Architecture (CORBA) Object Services model and is the standard for Object Request Broker (ORB) implementations. Some servers implement the Java APIs for the OTS rather than for JTA (see "JTA Controlled Transactions").
Use TopLink OTS support with the unit of work to directly access the Java OTS interfaces of servers that do not support JTA.
To integrate your application with an OTS transaction service, you must configure your application to use a custom server platform (see "Configuring the Server Platform").
For more information, see "Integrating the Unit of Work With an External Transaction Service".
Entity beans that use container-managed persistence may participate in transactions that are either client demarcated or container demarcated.
A client demarcated transaction occurs when a client of an entity bean directly sets up transaction boundaries using the javax.transaction.UserTransaction interface.
A container demarcated transaction occurs when the container automatically wraps an invocation on an EJB in a transaction based upon the transaction attributes supplied in the EJB deployment descriptor.
In transactions involving EJB, TopLink waits until the transaction begins its two-phase commit process before updating the database. This allows for the following:
SQL optimizations that ensure only changed data is written to the data source
Proper ordering of updates to allow for database constraints
For more information, see "Integrating the Unit of Work with CMP".
The unit of work does not directly participate in database transaction isolation. Because the unit of work may execute queries outside the database transaction (and, by interacting with the cache, outside the database itself), the database does not have control over this data and its visibility.
However, by default, TopLink provides a degree of transaction isolation regardless of what database transaction isolation has been configured on the underlying database.
Each unit of work instance operates on its own copy (clone) of registered objects (see "Clones and the Unit of Work"). In this case, because the unit of work provides an API that allows querying to be done on object changes within a unit of work (see "Using Conforming Queries and Descriptors"), the unit of work provides read committed operations.
Optimistic locking, optimistic read locking, or pessimistic locking can be used to further manage concurrency (see "Locking and the Unit of Work").
Changes are committed to the database only when the unit of work commit method is called (either directly or by way of an external transaction controller).
For detailed information on configuring and using TopLink to achieve a particular level of transaction isolation and transaction isolation level limitations, see "Database Transaction Isolation Levels".
