It is important to understand that the lock by itself does not protect resources in any way. Even if a foreign lock exists for a specific resource, applications could still perform any operation on it. Applications are expected to cooperate and respect locks consistently.

The standard lock-usage flow is:

• retrieve the lock
• if successful:
  • start reading the object, open the editor and allow to modify the object
  • apply modifications to the unit
  • save the modifications to the unit
  • repeat these two steps if appropriate
  • close the editor and release the lock
• else:
  • read the object, but do not allow to modify it.

The Pcd GL makes sure that at any given point in time there is not more than one lock active for a given resource. In order to detect and communicate potential conflicts, a user and session identifier have to be provided when requesting a lock.

It is important to differentiate between locks and lock objects:

• A lock is an entry in the central lock registry.
• Lock objects are Java objects that provide information about a specific lock.

The difference becomes apparent, when lifecycles are considered:

• A lock exists as long as the respective information is stored in the central lock registry.
• The lifecycle of a lock object is not determined by the lock registry but by the application that keeps a reference to this object. An application might keep a lock object for a longer time than the actual lock exists. Or it can drop the lock object without releasing the lock. In order to behave consistent, applications have to check and modify the lock state through new or existing lock-object instances.

The lock object (instances of ILock) can be in one of the following states:

1. ACTIVE: The lock object is backed by a lock in the registry.
2. INACTIVE: The lock object is not backed by lock in the registry - the resource is not locked!
3. BROKEN: There exists a lock for the same resource, which is associated with the ILock-instance, but either user id or session id differ. This means that after creation of the ILock-instance, some other user or session has obtained the lock.  

A lock is usually owned by the user who requested it. However, it is sometimes necessary that other users can take the lock away from the original owner, because he/she forgot to release the respective resource. In a productive environment this clearly is an exceptional case. It can happen if e.g. an application is terminated irregularly so that stale locks stay in the registry.

In the Pcd GL, locks have a configurable protection-time, and an even longer life-time. During the protection-time, only the lock-owner or an admin can release a lock. After the protection-time, the lock is still valid, but can be released by any user. At the end of the lock-lifetime, the lock is released automatically.