JPA Access Intent
Java Persistence API (JPA) access intent specifies the isolation level and lock level used when reading data from a data source. Access intent controls the JDBC isolation level and whether read, update or exclusive locks are acquired when retrieving data.
New feature: For a JPA persistence provider on the appserver, the application can specify isolation and ReadLockMode based on a TaskName. The TaskName provides a better control over applying these characteristics.
The application defines a set of entity types and their corresponding access intent for each TaskName defined in a persistence unit.
Access intent is available for application in the Java EE server environment.
Access intent is applicable to non-query entity manager interface methods. Query should use query hint interface to set its isolation and read lock values.
Access intent is only available for DB2 databases.
Access intent is in effect only when pessimistic lock manager is used. Add the following to the persistence unit's property list...
<property name="openjpa.LockManager" value="pessimistic"/>
The following table compares the EJB 2.x entity bean access intent with the JPA access intent properties:
WebSphere EJB 2.x entity bean access intent JPA access intent Description optimistic isolation: Read Committed Data is read but no lock is held. Version id is used on update to insure data integrity. Other transactions can read and update data. lockManager: Optimistic
query Hint: ReadLockMode: READ
pessimistic read isolation: Repeatable Read Data is read with shared locks. Other transactions attempting to update data are blocked. lockManager: Optimistic
query Hint: ReadLockMode: READ
pessimistic update isolation: Repeatable Read Data is retrieved with update or exclusive lock. Other writes are blocked until commit. This access intent can be used to serialize update access to data when there are multiple writers. lockManager: Pessimistic
query Hint: ReadLockMode: WRITE
pessimistic exclusive isolation: Serializable Data is retrieved with update or exclusive lock. Other writes are blocked until commit. This access intent can be used to serialize update access to data when there are multiple writers. lockManager: Pessimistic
query Hint: ReadLockMode:WRITE
A TaskName is set on a transaction context by one of the following:
- TaskName is automatically set via the EJB container when a transaction begins using...
- WebSphere local transaction (EJB unspecifid transaction)
- JTA global transaction in a Container-Managed Transaction (CMT)
- user-initiated global transaction in a Bean-Managed Transaction (BMT)
- TaskName is manually set in an application using the TaskNameAccessor
The advantage of using task names is that the access intent can be specified on a request scope rather than specifying it in the persistence.xml file, which has an application scope across all entities. Often a query is contained in a method or component which is used in many different transaction contexts.
Some of these contexts may require repeatable-read and update lock intent but other contexts do not.
Isolation level and read locks can be specified on:
- An application scope in the persistence.xml file.
These isolation level and read lock type are properties specified in the persistence.xml file. They apply to all entities define in the persistence unit.
- A transaction scope via task name. Transaction scoped hints will override application scope values.
- Query instance with a query hint.
Query hint can be used to override isolation and ReadLockMode for a particular query instance. A query hint will override isolation level and read locks specified at the application or transaction scope.
Related concepts
Access intent service
Set a TaskName using TaskNameAccessor
Specify TaskName in a JPA persistence unit
Related tasks
Task overview: Storing and retrieving persistent data with the Java Persistence API (JPA)