Working with Optimistic Locking

When using caching to provide performance benefits, you should also use a locking policy to manage database record modification in multi-user environments. Without a locking policy, it may be possible for users to see data that is no longer valid (sometimes called stale data) stored in the cache.

Databases typically support the following locking policies:

Optimistic – All users have read access to the data. When a user attempts to write a change, the application checks to ensure the data has not changed since the last read. OracleAS TopLink supports multiple methods of optimistic locking.
Pessimistic – The first user who accesses the data with the purpose of updating locks the data until completing the update. OracleAS TopLink supports pessimistic locking through UnitOfWork and updateAndLockObject().
No locking – The application does not verify that data is current.

Oracle recommends using optimistic locking to ensure that all users are working with valid data before committing changes. OracleAS TopLink supports multiple locking policies for optimistic locking:

Version locking policies enforce optimistic locking by using version fields (or write lock fields) that are updated each time a record version field must be added to the table for this.

Field locking policies do not require additional fields, but do require a UnitOfWork to be implemented.

Note:

If a three-tier application is being built and objects are edited outside the context of a unit of work, then the write lock value is stored in the object and passed to the client. If it is only the server, then lock conflicts may be missed as clients update the same cache.

Using Version Locking Policies

For each of the following version locking policies, you must add a specific database field.

For VersionLockingPolicy, add a numeric field.
For TimestampLockingPolicy, add a timestamp field.

OracleAS TopLink records the version as it reads an object from a table. When the client attempts to write the object, OracleAS TopLink compares the version of the object with the version in the table record.

If the versions are the same, the updated object is written to the table, and the version of both the table record and the object are updated.
If the versions are different, the write is disallowed because another client must have updated the object since this client initially read it.

The two version locking policies have different ways of writing to the database:

For VersionLockingPolicy, the number in the version field increments by one.
For TimestampLockingPolicy, a new timestamp is inserted into the row (this policy can be configured to get the time from the server or locally).

For both policies, the values of the write lock field can be the writable mapping within the object.

If the value is stored in the identity map, then by default an attribute mapping is not required for the version field. If the application does map the field, it must make the mappings read-only to allow OracleAS TopLink to control writing the fields.

Using Field Locking Policies

The following locking policies, included in OracleAS TopLink, do not require any additional fields:

AllFieldsLockingPolicy
ChangedFieldsLockingPolicy
SelectedFieldsLockingPolicy

All these policies compare the current values of certain mapped previous values. When using these policies, a UnitOfWork must be employed for updating the database. Each policy handles its field comparisons in specific way, as defined by the policy.

Whenever an object using AllFieldsLockingPolicy is updated or deleted, all the fields in that table are compared in the where clause. If any value in that table has been changed since the object was read, the update or delete fails.

Note:

This comparison is only on a per table basis. If an update is performed on an object that is mapped to multiple tables (multiple table inheritance), then only the changed table(s) appear in the where clause.

Whenever an object using ChangedFieldsLockingPolicy is updated, only the modified fields are compared. This allows for multiple clients to modify different parts of the same row without failure. Using this policy, a delete compares only on the primary key.
Whenever an object using SelectedFieldsLockingPolicy is updated or deleted, a list of selected fields is compared in the statement. Updating these fields must be done by the application manually or through an event.

Whenever any update fails because optimistic locking has been violated, an OptimisticLockException is thrown. This should be handled by the application when performing any database modification The application must refresh the object and reapply its changes.

Specifying Advanced Optimistic Locking Policies

The OracleAS TopLink optimistic locking policies that "Working with Optimistic Locking" describes implement the OptimisticLockingPolicy interface, referenced throughout the OracleAS TopLink code. You can create more policies by implementing this interface and implementing the methods defined.

Use the Locking tab (see Figure 4–22) to specify locking policies for the OracleAS TopLink Mapping Workbench, or refer to the Oracle Application Server TopLink Application Developer's Guide for more information.