Explicit hierarchical locking in data sharing

In Db2 data sharing, Db2 uses explicit hierarchical locking to determine whether propagating L-locks beyond the local IRLM to XES and to the coupling facility is necessary.

With explicit hierarchical locking, IRLM grants child locks locally when no inter-Db2 read/write interest exists on the parent. Granting lock requests locally, versus globally, improves performance.

Locks on the higher objects are parent locks. Locks on lower level objects are child locks, with the caveat that a child lock can be the parent of another child lock. While a lock is held, the first lock on the top parent is always propagated to XES and the lock structure. Thereafter, only more restrictive locks are propagated. When the lock is released, the process begins again. For partitioned table spaces, each locked partition is a parent of the child locks that are held for that partition. Explicit hierarchical locking is based on the lock hierarchy that is shown in the table below.

Table 1. Lock hierarchy. Indexes are not included in the hierarchy because index pages are protected by locks on the corresponding data.
Parent Children or child
UTS or partitioned table space Data pages and rows
Segmented table space Data pages and rows
Tables in a segmented table space N/A
LOB table space LOB
XML table space XML document
Simple table space Data pages and rows

When you use locking protocol 1, locks on child objects are based on contention on the parent L-lock. When you use locking protocol 2, locks on child objects are propagated depending on the compatibility of the page set P-lock with the page set P-locks that are held by other members for the table space.

The following table shows the conditions that cause the child locks to be propagated when locking protocol 1 is used.

Table 2. Determining when child locks are propagated to XES when locking protocol 1 is used
Maximum page set L-lock mode of this member is … And the maximum page set L-lock mode of other members is… Are X, L-child locks propagated by this member? Are S, L-child locks propagated by this member? Are U, L-child locks propagated by this member?
IS, S None, IS, S N/A No N/A
X None N/A N/A N/A
IS IX, SIX N/A Yes N/A
IX, SIX IS Yes No Yes
IX IX Yes Yes Yes
IX, SIX None No No No

The following table shows the conditions that cause the child locks to be propagated when locking protocol 2 is used.

Table 3. Determining when child locks are propagated to XES when locking protocol 2 is used
Maximum page set P-lock mode of this member is … And the maximum page set P-lock mode of the other members is… Are X, L-child locks propagated by this member? Are S, L-child locks propagated by this member? Are U, L-child locks propagated by this member?
IS, S None, IS, S N/A No Yes
X None No No No
IS IX, SIX N/A Yes Yes
IX, SIX IS Yes No Yes
IX IX Yes Yes Yes
SIX None Yes No No
IX None No No No
Notes:
  • Some child L-locks might be acquired before the page set P-lock is obtained. When this happens, child L-locks are automatically propagated.
  • When a page set switches from inter-system read/write interest to no inter-system read/write interest, a short period of time exists when the page set remains GBP-dependent, before the P-lock reverts to X state. During this time, child L-locks continue to be propagated.