Global locking in DB2 data sharing

Why global locks exist

Data sharing means every member can read and write the same user data and the same catalog. Isolation levels (CS, UR, RS, RR) still mean what they meant on a standalone subsystem. The extra problem is inter-member interest: member DB1A holds a page in BP2 while member DB1B wants to update that page. Without a group-wide lock manager, DB1B could overwrite DB1A’s buffer.

Db2 does not pass lock messages around the sysplex like a chatty protocol. Each IRLM talks to the coupling facility (CF) using z/OS cross-system extended services (XES). Granting an uncontended global lock is a CF request measured in microseconds on healthy hardware. Contention, not the happy path, is what hurts elapsed time.

The lock structure

The lock structure is a CF structure, usually named groupname_LOCK1 (for example DSNCAT_LOCK1). You define it in the CFRM policy with an INITSIZE, SIZE, preference list of CFs, and often ALLOWAUTOALT(YES) so XES can grow record-list space within SIZE. DISPLAY XCF,STR shows whether it is ALLOCATED and whether a duplexing rebuild is in progress.

IBM documents two parts inside LOCK1:

• Lock table — hash classes used to detect whether inter-Db2 read/write interest exists on a resource
• Record list (modify lock list) — currently held update locks, kept so a failed member’s locks can become retained locks and block other members from changing unprotected data

IRLM hashes the resource name to a lock-table entry. If that hash class is free, XES grants the lock with one CF interaction. If another member already owns an incompatible interest on that hash class, XES reports contention and IRLMs negotiate.

1
2
3
4
D XCF,STR,STRNAME=DSNCAT_LOCK1
 
-DISPLAY GROUP
-DISPLAY DATABASE(...) LOCKS

Lock structure duplexing keeps a secondary copy on another CF. If the primary structure or a CF link fails, processing continues on the surviving instance. Duplexing is an availability choice: it costs extra CF writes on the lock path. Shops with two robust CFs often duplex LOCK1 and SCA; GBP duplexing is a separate decision driven by changed-page loss risk.

How a lock request travels

1. The application issues SQL. Db2’s data manager asks IRLM for a lock.
2. Local IRLM grants immediately if no local conflict exists.
3. If the resource may be of inter-member interest, IRLM sends the request to XES for the lock structure.
4. Only the most restrictive mode held on that object by this member is propagated. A second local lock that is equal or weaker does not need another CF trip.
5. At COMMIT, unlocks can be batched to XES (especially with CFLEVEL 2 or higher).

Locks that go beyond local IRLM (except transaction L-locks in some ownership details) are owned by the member, which is why propagation can be reduced to the strongest mode. Child lock propagation (pages and rows) depends on parent interest and locking protocol.

L-locks (logical / transaction locks)

L-locks are the locks you already met: table space, partition, page, row, and so on. They implement isolation. In data sharing they are global transaction locks when another member cares about the same object. Duration still follows the isolation level and whether you updated the row.

Partitioned table spaces treat each partition as a separate parent lock. That limits how often a whole table space becomes a global bottleneck. Lock size (ANY, PAGE, ROW, TABLESPACE) still matters: a row lock that must be propagated for every row is more CF traffic than a well-chosen page lock on a quiet partition.

P-locks (physical locks)

P-locks exist because of data sharing. They are not a substitute for COMMIT. They answer “which members have this page set open, and does anyone need to write?” When two or more members have interest and at least one is read/write, the page set becomes GBP-dependent. Changed pages go to the group buffer pool so other members do not read down-level local buffers. Cross-invalidation tells other members to refresh.

P-locks are negotiable. Members can downgrade modes as interest changes (for example when the last updater closes the page set). They are owned by the member, survive individual COMMITs, and are negotiated on SRBs in DBM1. Page P-locks also protect cached page coherency inside a GBP-dependent page set.

Inter-member interest can exist on the L-lock and not the P-lock, or the reverse. Protocol 2 uses the page set P-lock to drive both GBP-dependency and child lock propagation. You do not code P-locks in SQL; you see them in traces, DISPLAY, and performance reports.

Global contention

Global contention is any wait that involved XES or the lock structure. Break it into kinds before you tune:

False contention

The lock table is a hash. Two different resources can land in the same hash class. XES then thinks there might be a conflict and IRLMs must talk. That extra work is false contention. It is not an application deadlock. The textbook fix is to enlarge the lock table (more entries) so collisions drop. Statistics in RMF Coupling Facility reports and IRLM/Db2 lock traces separate false from real. A common target is to keep false contention to a very small percentage of lock requests.

Real contention still wants the usual remedies: shorter units of work, the right isolation, avoid lock escalation, design clustering so hot pages are not a single-row traffic jam, and do not hold locks over a terminal wait. Data sharing does not invent those problems; it multiplies their cost because the wait may include CF and XES.

What beginners should remember

• Same SQL, extra infrastructure: IRLM + XES + LOCK1
• L-locks serialize transactions; P-locks keep buffers honest
• GBP-dependency starts when inter-Db2 read/write interest appears
• Size LOCK1 for false contention; duplex it for CF failure
• DISPLAY GROUP and D XCF,STR are the first operator windows

Explain It Like I'm Five

Imagine two kitchens sharing one pantry. Each kitchen has a clipboard (local IRLM). The building also has a magnetic board in the hallway (the lock structure). When you take the last jar of jam, you put a magnet on the board so the other kitchen does not take it too. L-locks are “I am using this jar until I finish my sandwich.” P-locks are “this kitchen still has the pantry open and might cook.” Sometimes two different jars get the same magnet hook (false contention)—the hallway thinks there is a fight when there is not, so you buy a bigger board with more hooks.

Exercises

1. Name the three components a global lock request can pass through after SQL starts.
2. Explain in one sentence why P-locks are not released at every COMMIT.
3. A report shows high false contention and low real contention. What do you size first?
4. Why does propagating only the most restrictive mode per member reduce CF traffic?
5. Look up your group’s LOCK1 structure name and whether it is duplexed (D XCF,STR).