Difference between Share lock and Exclusive lock

Lock

VSAM record-level sharing has multiple lock structures that are defined in the active storage management subsystem (SMS) configuration. The multiple, secondary lock structures can be defined by using the parameter, Lock Set, in the SMS Storage Class definition. Using the lock set attribute, additional Coupling Facility DFSMS Lock Structure to be associated with a single SMS storage class. VSAM supports two types of locks for files accessed in RLS mode. These two types are:

  • Exclusive Lock 
  • Shared Lock
Sr No.Exclusive LockShared Lock
1.The Exclusive Lock is used and valid on a single transaction, that locks either row or a page depending on the data. The shared lock ensures that a record is not in the process of being updated during a read-only request. It is also used to prevent updates of a record between the time that a record is read and the next sync point.
2.An exclusive lock is read as well as a write lock.A shared lock is basically a read-only lock for a row level.
3.It protects updates to file resources, both recoverable and non-recoverable.A Shared Lock is basically a read-only lock for a row level. Any number of resources can fetch the data to read when the shared lock is present on the resource.
4.This lock is issued when a transaction wants to update unlocked items.This lock is issued when a transaction wants to read an item that doesn’t have an exclusive lock.
5.There cannot be more than one exclusive lock on the same resource. Many process IDs can have a shared lock on the same resource to read the respective data.
6.Any transaction that requires an exclusive lock must wait if another task currently owns an exclusive lock or a shared lock against the requested resource.Several tasks can own shared locks, there are some circumstances in which tasks can be forced to wait for a lock: A request for a shared lock must wait if another task currently owns an exclusive lock on the resource. A request for an exclusive lock must wait if other tasks currently own shared locks on this resource. A new request for a shared lock must wait if another task is waiting for an exclusive lock on a resource that already has a shared lock.