Skip Headers

# Using Optimistic Read Locking With forceUpdateToVersionField

Previous

Next

If your descriptors are configured to use an optimistic version locking policy (see "Optimistic Version Locking Policies") or field locking policy (see "Optimistic Field Locking Policies"), use the unit of work method `forceUpdateToVersionField` to solve either or both of the following problems:

- You want an `OptimisticLockingException` thrown at commit time if an object you read in a transaction has changed since it was registered even though you have not changed the object in your transaction (see "Forcing a Check of the Optimistic Read Lock").

- You modify an object in a transaction in such a way that its version field is not updated but you want to alert other threads of the change by way of the version field (see "Forcing a Version Field Update").

  For example, you change a privately owned object that has its own database table so the parent object's version field is not, by default, updated. In this case, you can use `forceUpdateToVersionField` to update the parent's version field.

  As an alternative to this approach, consider "Optimistic Version Locking Policies and Cascading".

To remove `forceUpdateToVersionField` configuration from an object before a commit operation, use the unit of work method `removeForceUpdateToVersionField` (see "Disabling forceUpdateToVersionField").