Claims and drain locks are used to control currency between SQL processes and utilities, with partition independence being a major focus. Utilities and SQL can concurrently access and update different partitions, including different logical partitions of nonpartitioned indexes. NOTE | A logical partition refers to the set of index entries that point to rows in a particular data partition. Logical partitions exist only in nonpartitioned indexes of partitioned tables. An index entry belongs to one and only one logical partition. | Claims When an application first accesses an object within a unit of work, it makes a claim on the object. It releases the claim at the next commit point. Unlike a transaction lock, the claim cannot persist past the commit point. To access the object in the next unit of work, the application must make a new claim. Claims can be acquired on: -
Simple tablespace -
Segmented tablespace -
Index space -
Data partition -
Index partition There are three different claim classes: write, repeatable read, and cursor stability; they are described in Table 16-6. Table 16-6. Claim Classes Claim Class | Isolation Level | Allows Reading | Allows Updating | Allows Inserting | Allows Deleting | Write | Any | yes | yes | yes | yes | Repeatable read | RR | yes | no | no | no | Cursor stability | CS | yes | no | no | no | Claims are released at COMMIT except for utilities and cursors defined WITH HOLD still positioned on an object. All SQL processes are claimers, but only occasionally is a utility a claimer (e.g., online load resume). NOTE | There is no limit in DB2 to the number of concurrent claimers. | Drains Drain locks are used to serialize access to partitions and page sets among utilities, commands, and SQL applications. The drain is initiated at any time, but the actual takeover of an object occurs only when all access to the object has been quiesced. The drain process acquires a lock to prevent subsequent access from occurring until the lock is released. To drain a resource, a utility or command first acquires a drain lock and then waits until all claimers of a particular class on the resource are released. When all claims on the resource in a claim class are released, the resource is considered drained. A utility trying to take over can time out if a long-running SQL process does not release the claim quick enough. A utility that needs only read-only access will drain on the write class, which will prevent any new updating claimers. A utility that needs to change data will drain all claim classes. |