ejb.isolationLevel

**Table 2-1: Logical isolation level values**
Setting	Effect
`ReadCache`	Queries are satisfied by reading from the local query cache if possible. Otherwise, data is loaded from the remote database. Not recommended, as use of this isolation level can result in “lost” updates: updates made from the entity bean may go through even if the data has been modified since first read from the database. If lost updates are unacceptable, use `ReadCacheVerifyUpdates` and verify that the concurrency control configuration allows for locking or OCC version control.
`ReadCacheVerifyUpdates`	Queries are satisfied by reading from the object cache if possible. Otherwise, data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update or delete verifies that the data was not changed after it was loaded from the DBMS. This setting is suitable when it is acceptable for a read-only transaction to use stale cache data. To limit the use of stale data, specify a cache timeout by setting the cacheTimeout attribute for the <persistentObject> command, or by setting the cacheTimeout attribute for <queryMethod> commands.
`ReadCommitted`	Queries are satisfied by reading from the remote database. If the entity is changed or removed, the corresponding SQL update or delete does not verify that the data was not changed after it was loaded from the DBMS. Not recommended, as use of this isolation level can result in “lost” updates. If lost updates are unacceptable, use `ReadCommittedVerifyUpdates` and verify that the concurrency control configuration allows for locking or OCC version control.
`ReadCommittedVerifyUpdates`	Queries are satisfied by reading from the remote database. If the entity is changed or removed, the corresponding SQL update or delete verifies that the data was not changed after it was loaded from the DBMS. This setting provides a good balance of data integrity and performance. However, for some application data models, the maintenance of full data integrity requires a higher isolation level such as `RepeatableRead`. `ReadCommittedVerifyUpdatesWithCache` may provide better performance.
`ReadCommittedWithCache`	Queries are satisfied by reading from the object cache if possible. Otherwise, data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update or delete does not verify that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, and only if data was loaded from the local cache, a commit-time verify step ensures that the data has not changed since it was originally loaded from the DBMS. This ensures that any cached data that was used is still current at commit time, but does not prevent concurrent or conflicting updates. This setting is not recommended, as it can result in lost updates. Instead, use `ReadCommittedVerifyUpdatesWithCache`.
`ReadCommittedVerifyUpdates WithCache`	Queries are satisfied by reading from the local cache if possible. Otherwise data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update/delete verifies that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, and only if data was loaded from the local cache, a commit-time verify step ensures that the data has not changed since it was originally loaded from the DBMS. This ensures that any cached data that was used is still current at commit time. This setting does not prevent concurrent updates but does prevent conflicting updates. This setting is suitable when it is not acceptable for a read-only transaction to use stale data, and where commit-time verification is cheaper than satisfying queries from the DBMS; in particular, where a table timestamp is specified with the <persistentObject> tableVersion attribute, or where a JDBC/JIT driver wrapper is used (the JIT driver wrappers can batch verification statements together at commit-time).
`RepeatableRead`	Queries are satisfied by reading from the remote database. If the entity is changed or removed, the corresponding SQL update or delete will verify that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, a commit-time verification ensures that the data has not changed since it was loaded from the DBMS. If pessimistic locking is enabled with the <persistentObject> selectWithSharedLock or selectWithUpdateLock attribute, and is supported by the DBMS, verification is skipped as the shared/exclusive locks that are obtained at load time will prevent conflicting updates. WARNING! Pessimistic locking may increase the occurrence of deadlock. This setting is suitable for cases where uncontrolled concurrent updates may result in data integrity problems (even for read-only access). `RepeatableReadWithCache` may provide better performance, although if many transactions are updating the same rows, pessimistic locking with no cache is probably preferable.
`RepeatableReadWithCache`	Queries are satisfied by reading from the local cache if possible. Otherwise, data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update or delete verifies that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, a commit-time verification ensures that the data has not changed since it was originally loaded from the DBMS. This setting is suitable for cases where uncontrolled concurrent updates may result in data integrity problems (even for read-only access), where it is not acceptable for a read-only transaction to use stale cache data, and where commit-time verification is cheaper than satisfying queries from the DBMS; in particular, where a table timestamp is specified with the <persistentObject> tableVersion attribute, or where a JDBC/JIT driver wrapper is used (the JIT driver wrappers can batch verification statements together at commit-time). If many transactions from other sources are updating the same rows, you may get better performance using `RepeatableRead` with pessimistic locking.
`Serializable`	Like `RepeatableRead`, except guarantees that the set of rows satisfying the query cannot change before the current transaction completes. This isolation level is not supported when using Oracle databases. Use `RepeatableRead` instead, or add additional application-level data version checking code.
`SerializableWithCache`	Like `RepeatableReadWithCache`, except guarantees that the set of rows satisfying the query cannot change before the current transaction completes. This isolation level is not supported when using Oracle databases. Use `RepeatableReadCache` instead, or add additional application-level data version checking code.

Table 2-1: Logical isolation level values

Setting

Effect

ReadCache

Queries are satisfied by reading from the local query cache if possible. Otherwise, data is loaded from the remote database.

Not recommended, as use of this isolation level can result in “lost” updates: updates made from the entity bean may go through even if the data has been modified since first read from the database. If lost updates are unacceptable, use ReadCacheVerifyUpdates and verify that the concurrency control configuration allows for locking or OCC version control.

ReadCacheVerifyUpdates

This setting is suitable when it is acceptable for a read-only transaction to use stale cache data. To limit the use of stale data, specify a cache timeout by setting the cacheTimeout attribute for the <persistentObject> command, or by setting the cacheTimeout attribute for <queryMethod> commands.

ReadCommitted

Queries are satisfied by reading from the remote database. If the entity is changed or removed, the corresponding SQL update or delete does not verify that the data was not changed after it was loaded from the DBMS.

Not recommended, as use of this isolation level can result in “lost” updates. If lost updates are unacceptable, use ReadCommittedVerifyUpdates and verify that the concurrency control configuration allows for locking or OCC version control.

ReadCommittedVerifyUpdates

Queries are satisfied by reading from the remote database. If the entity is changed or removed, the corresponding SQL update or delete verifies that the data was not changed after it was loaded from the DBMS.

This setting provides a good balance of data integrity and performance. However, for some application data models, the maintenance of full data integrity requires a higher isolation level such as RepeatableRead.

ReadCommittedVerifyUpdatesWithCache may provide better performance.

ReadCommittedWithCache

Queries are satisfied by reading from the object cache if possible. Otherwise, data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update or delete does not verify that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, and only if data was loaded from the local cache, a commit-time verify step ensures that the data has not changed since it was originally loaded from the DBMS. This ensures that any cached data that was used is still current at commit time, but does not prevent concurrent or conflicting updates.

This setting is not recommended, as it can result in lost updates. Instead, use ReadCommittedVerifyUpdatesWithCache.

ReadCommittedVerifyUpdates WithCache

Queries are satisfied by reading from the local cache if possible. Otherwise data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update/delete verifies that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, and only if data was loaded from the local cache, a commit-time verify step ensures that the data has not changed since it was originally loaded from the DBMS. This ensures that any cached data that was used is still current at commit time. This setting does not prevent concurrent updates but does prevent conflicting updates.

This setting is suitable when it is not acceptable for a read-only transaction to use stale data, and where commit-time verification is cheaper than satisfying queries from the DBMS; in particular, where a table timestamp is specified with the <persistentObject> tableVersion attribute, or where a JDBC/JIT driver wrapper is used (the JIT driver wrappers can batch verification statements together at commit-time).

RepeatableRead

Queries are satisfied by reading from the remote database. If the entity is changed or removed, the corresponding SQL update or delete will verify that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, a commit-time verification ensures that the data has not changed since it was loaded from the DBMS.

If pessimistic locking is enabled with the <persistentObject> selectWithSharedLock or selectWithUpdateLock attribute, and is supported by the DBMS, verification is skipped as the shared/exclusive locks that are obtained at load time will prevent conflicting updates.

WARNING! Pessimistic locking may increase the occurrence of deadlock.

This setting is suitable for cases where uncontrolled concurrent updates may result in data integrity problems (even for read-only access).

RepeatableReadWithCache may provide better performance, although if many transactions are updating the same rows, pessimistic locking with no cache is probably preferable.

RepeatableReadWithCache

Queries are satisfied by reading from the local cache if possible. Otherwise, data is loaded from the remote database. If the entity is changed or removed, the corresponding SQL update or delete verifies that the data was not changed after it was loaded from the DBMS. Otherwise, for read-only access, a commit-time verification ensures that the data has not changed since it was originally loaded from the DBMS.

This setting is suitable for cases where uncontrolled concurrent updates may result in data integrity problems (even for read-only access), where it is not acceptable for a read-only transaction to use stale cache data, and where commit-time verification is cheaper than satisfying queries from the DBMS; in particular, where a table timestamp is specified with the <persistentObject> tableVersion attribute, or where a JDBC/JIT driver wrapper is used (the JIT driver wrappers can batch verification statements together at commit-time).

If many transactions from other sources are updating the same rows, you may get better performance using RepeatableRead with pessimistic locking.

Serializable

Like RepeatableRead, except guarantees that the set of rows satisfying the query cannot change before the current transaction completes.

This isolation level is not supported when using Oracle databases. Use RepeatableRead instead, or add additional application-level data version checking code.

SerializableWithCache

Like RepeatableReadWithCache, except guarantees that the set of rows satisfying the query cannot change before the current transaction completes.

This isolation level is not supported when using Oracle databases. Use RepeatableReadCache instead, or add additional application-level data version checking code.