|
Oracle® Application Server TopLink Application Developer's Guide
10g Release 2 (10.1.2) Part No. B15901-01 |
|
 Previous |
 Next |
|
Oracle® Application Server TopLink Application Developer's Guide
10g Release 2 (10.1.2) Part No. B15901-01 |
|
|
Previous |
Next |
This section describes generic database transaction concepts and how they apply to the OracleAS TopLink Unit of Work.
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 7-1. Each offers a trade-off between performance and resistance from the following unwanted behaviors:
Dirty read: a transaction reads uncommitted data written by a concurrent transaction.
Nonrepeatable read: a transaction re-reads data and finds it has been modified by some other transaction that committed after the initial read.
Phantom read: a transaction re-executes a query, and the returned data has changed due to some other transaction that committed after the initial read.
Table 7-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 |
| Serializeable | 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.
In OracleAS TopLink, transactions are encapsulated by the Unit of Work object. Like any transaction, a Unit of Work transaction provides:
Unit of Work operations occur within a Unit of Work context, 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.
If your application is a standalone OracleAS TopLink application, then your application demarcates transactions using the Unit of Work.
If your application includes a J2EE container that provides container-managed transactions, you can configure OracleAS TopLink to integrate with the transaction demarcation of the container. The Unit of Work supports:
J2EE containers use JTA to manage transactions in the application. If your application includes a J2EE container, the Unit of Work executes as part of an external JTA transaction. The Unit of Work still manages its own internal operations, but relies on the external transaction to commit changes to the database. The Unit of Work waits for the external transaction to commit successfully before writing changes back to the session cache.
Note that because the transaction happens outside the Unit of Work context and is controlled by the JTA, errors can be more difficult to diagnose and fix.
For more information, see "J2EE Integration".
Entity beans that use container-managed persistence can participate in either client-demarcated or container-demarcated transactions. They can demarcate transactions with the javax.transaction.UserTransaction interface. OracleAS TopLink automatically wraps invocations on entity beans in container transactions based on the transaction attributes in the EJB deployment descriptor. For more information about transactions with EJBs, see the EJB specification and your J2EE container documentation.
In transactions involving EJBs, OracleAS TopLink waits until the transaction begins its two-stage commit process before updating the database. This allows for:
SQL optimizations that ensure only changed data is written to the data store
Proper ordering of updates to allow for database constraints
OracleAS TopLink DatabaseLogin API allows you to set the transaction isolation level used when you open a connection to a database:
databaseLogin.setTransactionIsolation(DatabaseLogin.TRANSACTION_SERIALIZABLE);
However, the Unit of Work does not participate in database transaction isolation. Because the Unit of Work may execute queries outside the database transaction, the database has no control over the data and its visibility outside the transaction.
To maintain transaction isolation, each Unit of Work instance operates on its own copy (clone) of affected objects (see "Clones and the Unit of Work"). Multiple reads to the same object return the same clone, and the state of the clone is from when it was first accessed (registered).
Optimistic locking, optimistic read locking, or pessimistic locking can be used to ensure concurrency (see "Locking Policy").
The Unit of Work method ShouldAlwaysConformResultsInUnitOfWork allows querying to be performed on object changes within a Unit of Work (see "Using Conforming Queries and Descriptors").
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).
