A locking scenario

Looking at an example of locking activity between two members of a data sharing group can help you to understand locking in a data sharing environment.

Figure 1. A lock propagation scenario
Begin figure description. A timeline shows the chronology of transactions involving table space TS1 by members DB2A and DB2B. End figure description.
In the figure above:
  1. The L-lock on table space 1 (TS1), which is associated with transaction 2, is not propagated because DB2A already holds a lock of an equal restriction on that object. (The L-lock on TS1, which is associated with transaction 3, is propagated because that lock is from another member.)
  2. The child L-lock on page 1, which is associated with transaction 1, is not propagated at the time that it is requested because its parent lock is IS on both members: no inter-Db2 read/write interest exists on the parent.
  3. When Transaction 4 upgrades its lock to IX on TS1, its X lock on Page 2 must be propagated because inter-Db2 read/write interest now exists on the parent. Also, the child lock on Page 1, which is associated with transaction 1, must be propagated.

    The child lock is propagated under an IRLM SRB, not under the transaction's TCB. This propagation is counted in the statistics report as an asynchronous propagation, as shown in FALSE CONTENTION RATE (%) in the Db2 OMEGAMON® statistics trace.