How do you Avoid Database Resource Contention?

OC4J and the TopLink EJB 3.0 JPA persistence provider and EJB 2.1 persistence manager use a combination of transaction isolation (see "Transaction Isolation") and concurrency mode (see "Concurrency (Locking) Mode") to avoid database resource contention and to permit concurrent access to database tables.

Transaction Isolation

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 1-21. 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 re executes a query and the returned data has changed due to some other transaction that was committed after the initial read operation.

Table 1-21 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

By default, OC4J and the TopLink EJB 3.0 JPA persistence provider and EJB 2.1 persistence manager provide read-committed transaction isolation.

To configure the transaction isolation mode, you must customize the TopLink EJB 3.0 JPA persistence provider or EJB 2.1 persistence manager.

For more information, see the following:

• "Customizing the JPA Persistence Provider"

• "Customizing the TopLink EJB 2.1 Persistence Manager"

• "Unit of Work Transaction Isolation" in the Oracle TopLink Developer's Guide

• "Database Transaction Isolation Levels" in the Oracle TopLink Developer's Guide

Concurrency (Locking) Mode

OC4J also provides concurrency modes for handling resource contention and parallel execution within EJB 3.0 entities and EJB 2.1 entity beans with container-managed persistence.

Entity beans with bean-managed persistence manage the resource locking within the bean implementation themselves.

Concurrency modes include the following:

• Optimistic Locking: Multiple users have read access to the data. When a user attempts to make a change, the application checks a version field (also known as a write-lock field) to ensure the data has not changed since the user read the data.

  When optimistic locking is enabled, TopLink caches the value of this version field as it reads an object from the data source. When the client attempts to write the object, TopLink compares the cached version value with the current version value in the data source in the following way:

  • If the values are the same, TopLink updates the version field in the object and commits the changes to the data source.

  • If the values are different, the write operation is disallowed because another client must have updated the object since this client initially read it.

• Pessimistic Locking: The first user, who accesses the data with the purpose of updating it, locks the data until completing the update. This manages resource contention and does not allow parallel execution. Only one user at a time is allowed to execute the entity bean at a single time.

• Read-only: Multiple users can execute the entity bean in parallel. The container does not allow any updates to the bean's state.

These concurrency modes are defined for each bean and apply on the transaction boundaries.

By default, in EJB 3.0, the JPA persistence manager assumes that the application is responsible for data consistency. Oracle recommends that you use the @Version annotation to specify a version field and enable JPA-managed optimistic locking.

By default, in EJB 2.1, the TopLink persistence manager enforces optimistic locking by using a code-generated numeric version field that TopLink updates each time an object change is committed.

To configure the concurrency mode otherwise, you must customize the TopLink EJB 3.0 JPA persistence provider or EJB 2.1 persistence manager.

For more information, see the following:

• "Customizing the JPA Persistence Provider"

• "Customizing the TopLink EJB 2.1 Persistence Manager"

• "Locking" in the Oracle TopLink Developer's Guide

• "Configuring Locking Policy" in the Oracle TopLink Developer's Guide

• "Configuring Read-Only Descriptors" in the Oracle TopLink Developer's Guide