LockMethod...
Per the specification, a lock indicates that someone is updating the resource, (hence the lock is a "write lock"), although the specification notes that the the syntax is extensible, and permits the eventual creation of locking for other access types.
The most basic form of lock is an exclusive lock. This is a lock where the access right in question is only granted to a single client. The need for this arbitration results from a desire to avoid having to merge results. However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple clients to receive a lock. Hence any user with appropriate access can get the lock.
With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.
The following table indicates what happens if a new lock request is sent to a resource that is already locked:
| Lock Request | ||
|---|---|---|
| Current Lock | Exclusive Lock | Shared Lock |
| None | Success | Sucess |
| Shared | Failure | Sucess |
| Exclusive | Failure | Failure |
| |