Skip Headers

# Configuring Locking Policy

Previous

Next

You can configure a descriptor with a locking policy that prevents one user writing over another user's work.

Table: Descriptor Support for Locking Policy summarizes which descriptors support locking policies.

Descriptor Support for Locking Policy

Descriptor | Optimistic Version Locking Policies | Optimistic Field Locking Policies | Pessimistic Locking Policy | Using TopLink Workbench | Using Java
--- | --- | --- | --- | --- | ---
Relational DescriptorsFoot 1 |  |  |  |  |
Object-Relational Descriptors |  |  |  |  |
EIS DescriptorsFoot 2 |  |  |  |  |
XML Descriptors |  |  |  |  |

Footnote 1 Relational class descriptors only (see "Relational Class Descriptors").

Footnote 2 EIS root descriptors only (see "EIS Root Descriptors").

Oracle recommends that you use a locking policy. You should use a locking policy in any multiuser environment to prevent one user writing over another user's changes. Although locking can be particularly important if multiple servers or multiple applications access the same data, even in a single server application, the same locking issue still exists. In a multiple-server environment, locking is still relevant even if your application uses cache refreshing or cache coordination.

If you are building a three-tier application, in order to correctly lock an object, you must obtain the lock before the object is sent to client to be edited. The type of locking you choose has an influence on how you can achieve this (see "Locking in a Three-Tier Application").