Skip Headers

# Optimistic Field Locking Policies

Previous

Next

Optimistic field locking policies enforce optimistic locking by using one or more of the fields that currently exist in the table to determine if the object has changed since the client read the object.

The unit of work caches the original state of the object when you first read the object or register it with the unit of work. At commit time, the unit of work compares the original values of the lock fields with their current values on the data source during the update. If any of the lock field's values have changed, an optimistic lock exception is thrown.

TopLink provides the following optimistic field locking policies:

- `AllFieldsLockingPolicy`: For update and delete operations, TopLink compares all the fields of the object with all the fields in the data source. If the original value of any fields differ from that in the data source, the write operation is disallowed.

  For example, if you changed a customer's last name, TopLink might produce SQL like:

      UPDATE CUSTOMER SET LNAME='new last name' WHERE ID=7 AND LNAME='old last name' AND FNAME='Donald' AND B_DAY='1972' AND CREDIT_RATING='A+' AND EYE_COLOR='Blue'

  The main disadvantage of this field locking policy is that it is not the most efficient, especially if the changed object has many attributes.

  Note: This comparison is only on a per table basis. If an update operation is performed on an object that is mapped to multiple tables (multiple table inheritance), then only the changed fields for each table changed appear in the `where` clause.

- `ChangedFieldsLockingPolicy`: For update operations, TopLink compares only the fields of the object that have changed with the corresponding fields in the data source. If the original value of any such field differs from that in the data source, the write operation is disallowed. TopLink does not make any field comparisons for deletes.

  The main advantage of this field locking policy is that it allows concurrent updates of different fields. For example, if one thread updates a customer's last name and another thread updates the same customer's credit rating, and you configure the `Customer` descriptor with `ChangedFieldsLockingPolicy`, then TopLink might produce SQL like:

      // Unit of Work 1
      UPDATE CUSTOMER SET LNAME='new name' WHERE ID=7 AND LNAME='old name'
      // Unit of Work 2
      UPDATE CUSTOMER SET CREDIT_RATING='B' WHERE ID=7 AND CREDIT_RATING='A+'

- `SelectedFieldsLockingPolicy`: For update and delete operations, TopLink compares only the selected fields of the object with the corresponding fields in the data source. If the cached value of any such field differs from that in the data source, the write operation is disallowed.

  For example, if you select `Customer` attributes `LNAME` and `CREDIT_RATING`, then at run time, TopLink might produce SQL like:

      UPDATE CUSTOMER SET LNAME='new name' WHERE ID=7 AND LNAME='old name' AND CREDIT_RATING='A+'

Whenever any update fails because optimistic locking has been violated, TopLink throws an `OptimisticLockException`. This should be handled by the application when performing any database modification. The application must notify the client of the locking contention, refresh the object, and have the client reapply its changes.

When using field locking policies, a unit of work must be employed for updating the data source.

Note: You cannot use an instance of `FieldsLockingPolicy` if you are using `AttributeChangeTrackingPolicy` (see "Attribute Change Tracking Policy").