Working with Optimistic Locking

When using caching to provide performance benefits, you should also use a locking policy to manage database record modification in multiuser 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. 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. 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. 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.