Skip Headers

# Unit of Work Architecture

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: Transaction Isolation Levels. 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.

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 Transaction Context

- Unit of Work Transaction Demarcation

- Unit of Work Transaction Isolation