Resource Locks 
Use
To prevent the simultaneous modification of resources, the repository framework implements locks. The locks enable the framework to serialize access to resources and thus prevent the loss of data resulting from parallel updates.
Features
If an application wants to apply a lock, it issues a lock request for the resource and the user. If there is no other blocking lock on the resource, the application can obtain the lock. If a blocking lock already exists, the request is denied. Access of a particular kind, for example, read or write, is only allowed for users who obtain the relevant lock.
The behaviour of locks is controlled by the following characteristics:
● Scope controls how many users can request locks on a resource.
○ Shared locks allow several users to obtain a lock, but block exclusive locks and prevent any access without a lock.
○ Exclusive locks allow access for only one user and block all other users from obtaining a lock. They also prevent any access without locks.
● Kind specifies the type of operation for which the lock is valid and how many locks of this kind are permitted
○
Write locks
block any other write locks and prevent all write operations without locks.
They allow further read locks.
Write operations occur when there is a change to content, properties, or the
namespace.
○
Read locks
allow other read locks to be obtained, but block all write locks and prevent
read operations without locks.
Read operations take place when resources or resource properties and content
are retrieved.
● Depth controls the levels in the hierarchy that a lock applies to.
○ Shallow locks only apply to the resource for which they are issued.
○ Deep locks apply to all resources in the hierarchy below the locked resource. Linked resources (the link targets) are not affected by the lock if they are located outside the hierarchy of the locked resource.
●
Timeout specifies when a lock expires and is
automatically released.
This is useful in a distributed web scenario where a remote application holds
a lock on a resource, but cannot release the lock because the connection to
the server has broken.
A shallow, exclusive write lock prevents all other modifying access and blocks all other write locks, but allows further read locks. If a collection is locked all operations which modify the list of children, including the creation of children, are also locked.
Once an application holds a lock on a resource, it cannot lock the resource again. Therefore methods are available to check whether a lock already exists and to find out the user to whom it is assigned. If the lock has a timeout, the application must refresh the lock to extend the timeout and not relock the resource.
See also: