Concurrency and locks in data sharing environments

Concurrency and transaction locks have additional implications in data sharing environments.

Global transaction locking

With data sharing, concurrency control exists both within a specific member and among all members of a data sharing group. This means that locks used in data sharing are global transaction locks with a scope that includes the entire data sharing group. Many of these locks are processed by each of the following facilities:
  • The local IRLM
  • The z/OS® cross-system extended services (XES)
  • The coupling facility lock structure

Relationship between L-locks and P-locks

Transaction locks are often called logical locks (L-locks) in data sharing.

Data sharing also uses physical locks (P-locks). But, P-locks are related to caching, not concurrency. These locks use different mechanisms than the transaction locks you are familiar with in Db2.

Inter-member interest occurs between more than one Db2 member in a data sharing group. Inter-member interest is possible on an L-lock but not on a P-lock that is held on the same object. Inter-member interest is also possible on the P-lock but not on the L-lock. The inter-member interest on the page set P-lock, in locking protocol 2, controls both GBP-dependency and child lock propagation.

Locking optimizations for data sharing

Db2 uses the following optimizations to reduce the necessity of processing locks beyond the local IRLM whenever possible.
  • Explicit hierarchical locking makes certain optimizations possible. When no inter-member read/write interest exists in an object, it is possible to avoid processing certain locks beyond the local IRLM.
  • If a single member with update interest and multiple members with read-only interest exist, Db2 propagates fewer locks than when all members have update interest in the same page set.
  • All locks (except L-locks) that are held beyond the local IRLM are owned by a member, not by an individual work unit. This ownership scope reduces lock propagation. It requires that only the most restrictive lock mode for an object on a given member is propagated to XES and the coupling facility. A new lock that is equal to, or less restrictive than, the lock currently being held is not propagated.
  • When the lock structure is allocated in a coupling facility of CFLEVEL=2 or higher, IRLM can release many locks with just one request to XES. This release can occur, for example, after a transaction commits and has two or more locks that need to be unlocked in XES. It also can occur at Db2 shutdown or abnormal termination when the member has two or more locks that need to be unlocked.

Partition locks in data sharing

In a partitioned table space, locks are obtained at the partition level. Individual partitions are locked as they are accessed. This locking behavior enables greater concurrency.

Partition locks are always acquired, even if the table space was defined LOCKPART NO clause in a version of Db2 prior to Version 8. The LOCKPART NO clause is deprecated and no longer has any effect.

Each locked partition is a separate parent lock. Therefore, Db2 and IRLM can detect when no inter-Db2 read/write interest exists on that partition and thus do not propagate child L-locks unnecessarily.

Restrictions: If any of the following conditions are true, Db2 cannot selectively lock the partitions. It must lock all the partitions:
  • The table space is defined with LOCKSIZE TABLESPACE.
  • LOCK TABLE IN EXCLUSIVE MODE is used (without the PART option).