Active and retained locks for Db2data sharing members
Active locks, retained locks, and retained utility locks can be held by a failed member. Locks that are held by a failed member can affect the availability of data to the other members of the group that are still running Db2 applications.
Active locks
When a member is active, the locks that it holds are called active locks. For transaction locks (L-locks), the normal concurrency mechanisms apply, including suspensions and timeouts when incompatible locks are requested for a resource. For physical locks (P-locks), Db2 uses a negotiation process to control access.
Retained locks
The particular concern for availability is what happens to locks when a member fails. For data sharing, active locks used to control updates to data (modify locks) become retained in the event of a failure. This means that information about those locks is stored in the coupling facility until the locks are released during restart. Retained locks are necessary to protect data in the process of being updated from being accessed by another active member of the group.
Db2 has various types of retained locks, among them are L-locks, page set P-locks, and page P-locks. As long as a retained lock is held by a failed member, another member cannot lock the resource in a mode that is incompatible with the mode of the retained lock on that resource. Incompatible requests from other members are suspended if you specify a non-zero value for the RETAINED LOCK TIMEOUT parameter of installation panel DSNTIPI. Incompatible requests from other members are immediately rejected if you specify a value of 0 for this parameter.
In the case of a page set P-lock, it is conceivable that an entire page set could be unavailable. For example, an X mode page set P-lock is retained if the page set is non-GBP-dependent at the time of the failure. Incompatible lock requests from other members can be processed after the retained locks are removed, which occurs during restart. To keep data available for all members of the group, restart failed members as soon as possible, either on the same or another z/OS® system.
You
can restart a failed member in light
mode to quickly recover
the locks held by that member. Restarting in light mode is primarily
intended for a cross-system restart in the event of a failed z/OS system.
Retained utility locks
When a member is running a utility, it holds a lock on the utility ID (UID) for that utility. That lock is also retained if the member fails. This means that you cannot restart a utility until the failed member is restarted and the retained lock is converted to an active lock.
When retained locks are reacquired or purged
- Db2 converts the lock to active. This is called reacquiring the lock, and it is what Db2 does for page set P-locks.
- Db2 purges the lock. This is what Db2 does for page P-locks and for L-locks.
The following table shows how the restart processing for locks can happen at different times.
| Lock type | Processing |
|---|---|
| Page set P-lock | Reacquired when page sets are opened for log apply.
This generally happens during forward recovery or before restart completes. The earliest that a page set P-lock can become negotiable is at the end of forward recovery. If no log apply is needed, it can happen later, such as the end of restart processing. |
| Page P-lock | Purged at the end of forward recovery. |
| L-lock | Purged at the end of restart processing. |
If a member has a non-zero value for RETAINED LOCK TIMEOUT and it requests a lock that is incompatible with a retained lock, its applications can be suspended as long as the retained locks are held. Its request can go through as soon as the retained lock is purged or becomes negotiable. For example, if an application is suspended because of an incompatible retained page set P-lock, that retained lock most likely becomes active and available for negotiation at the end of forward log recovery.