Locking Within Central Version

Contents
idms
Contents
Logical Locks
Control Access to Resources
Logical locks are used within a central version and within a data sharing group to control access to database resources by concurrently executing transactions. Before a transaction can access a resource, it places a lock on the resource which prevents other transactions from modifying or, in some cases, accessing the resource while the lock is maintained.
In a data sharing environment, CA IDMS uses global transaction locks, maintained in a coupling facility lock structure to control inter-member access to shared resources.
For more information on global locking, see 39.5, “Locking Within a Data Sharing Group”.
Wait States
If a transaction attempts to lock a resource which is locked by another transaction with a conflicting mode, the first transaction will wait until the lock is released. If the waiting transaction exceeds the internal wait interval specified at system generation, CA IDMS aborts the transaction and rolls out its updates. If one transaction is waiting to place a lock and the transaction that holds it then waits on a lock held by the first transaction, a deadlock condition exists. CA IDMS resolves this condition by aborting and rolling back one of the transactions.
For more information on detecting and resolving deadlocks, see 39.7, "Deadlocks".
Hierarchical Locking
CA IDMS/DB uses a hierarchical locking scheme in which locks are placed at area and record occurrence (row) levels. Area locks control access to the area, and by implication, all record occurrences stored within the area. Record locks control access to individual record occurrences or rows.
A transaction intending to access data within an area must first place a lock at the area level. Depending on the strength of that lock (its mode), the transaction may or may not also place locks on individual record occurrences as it retrieves or updates them.
In a data sharing environment, CA IDMS uses a three-level hierarchy to control inter-member access to shared resources: area, proxy, and record occurrence.
For more information on this additional level, see 39.5.3, “Proxy Locks”.
Types of Locks
Lock Modes
Each logical lock has an associated lock mode. The mode of the lock determines whether the lock conflicts with other locks already held on the resource and with locks subsequently requested by other transactions.
The following types of locks (lock modes) are used for both area and record locks:
Mode
Identifier
Description
Share
S
Typically used to guarantee that no updates are made to data while a transaction is accessing it. A share lock is compatible with other share locks but not with exclusive locks. A share lock placed on an area implies a share lock on each record within the area.
Exclusive
X
Typically placed on a resource to protect transactions from accessing data that is being updated by the issuing transaction. An exclusive lock is incompatible with both share and other exclusive locks. An exclusive lock placed on an area implies an exclusive lock on all records within the area.
Null-lock
NL
A null-lock is a special type of lock which is placed on a record to signify a notify lock and on an area to signify transient retrieval access. Null-locks provide no protection against concurrent access.
Intent Locks on Areas
The following types of locks are placed only on areas:
Mode
Identifier
Description
Intent share
IS
Allows share (S) locks to be placed on records within the area.
Intent exclusive
IX
Allows exclusive (X) locks to be placed on records within the area.
Update intent exclusive
UIX
Allows exclusive locks to be placed on records within the area by the issuing transaction, but not by other transactions.
In addition to the above lock modes, the following lock mode has been provided for but is currently not used:
  • Update (U)---An update lock is placed on a resource if it might be updated after it is retrieved (in which case the lock would be upgraded to an exclusive lock).
Compatibility of Locks
For two transactions running within the same DC/UCF system to access the same area or row concurrently, their lock types must be compatible. When two transactions attempt to set locks that are not compatible, the first transaction to set a lock causes the second transaction to wait until the resource is freed.
CA IDMS ensures that a transaction does not compete with itself for locks.
Compatibility Chart
The following chart shows which lock modes are compatible and which are incompatible. The plus sign (+) indicates a situation in which two lock modes are compatible. The minus sign (-) indicates a situation in which two lock modes are incompatible.
NL
IS
IX
S
U
UIX
X
NL
+
+
+
+
+
+
+
IS
+
+
+
+
+
+
-
IX
+
+
+
-
-
-
-
S
+
+
-
+
+
-
-
U
+
+
-
+
-
-
-
UIX
+
+
-
-
-
-
-
X
+
-
-
-
-
-
-
Example
If TRANSACTION1 holds a share (S) lock on an area, TRANSACTION2 can set a null-lock (NL), intent-share (IS), share (S), or update (U) lock on the same area.
Logical Area Locks
Effect of Ready Mode
To control concurrent access to areas within a central version, the mode in which an area is readied is translated into a logical lock on the area. As an area is readied, CA IDMS/DB attempts to place an appropriate lock based on the ready mode. If the new lock doesn't conflict with locks already held by other transactions, access is granted to the area. If a conflict exists, the transaction is placed in a wait state until the conflicting locks are released.
Area Lock Depends on Area Ready Mode
The type of lock (lock mode) placed on an area depends on the mode in which the area is being readied:
Ready mode
Lock mode
Transient retrieval
Intent Share (NL)
Shared retrieval
Intent Share (IS)
Shared update
Intent Exclusive (IX)
Protected retrieval
Share (S)
Protected update
Update Intent Exclusive (UIX)
Exclusive retrieval
Exclusive (X)
Exclusive update
Exclusive (X)
When Area Locks are Acquired
For transactions initiated through navigational DML, CA IDMS/DB acquires area locks when either of the following occur:
  • The first non-ready DML (other than BIND RECORD) statement is issued following one or more READY statements
  • The first non-bind statement is issued within a transaction using default ready modes specified by the subschema
For SQL-initiated transactions, when area locks are acquired depends on the area acquisition mode specified within an access module or in effect for dynamic SQL.
For more information, see 39.4.4, “Area Locking for SQL Transactions".
Area Acquisition Threshold
If a transaction is locking multiple areas at one time, and must wait to place a lock on one of the areas, CA IDMS/DB releases the locks on all other areas before placing the transaction in a wait state. This helps to avoid deadlocks between two or more transactions trying to gain access to areas. However, it also means that another transaction can gain access to an area whose lock was released by the waiting transaction. To avoid this pre-emption, you can specify an area acquisition threshold at system generation that limits the number of times a transaction will wait on an area lock before it no longer releases other area locks.
Area Locking for SQL Transactions
When Area Locks are Acquired
The time at which area locks are acquired for SQL transactions varies depending on the lock acquisition mode in effect. There are two lock acquisition modes:
  • Preclaim
  • Incremental
On First Database Access
The preclaim mode directs CA IDMS to place locks on all areas in a transaction that use the preclaim acquisition mode as soon as the first statement that requires access to the
database
is executed.
You can use the preclaim mode to reduce the likelihood of deadlocks. A transaction that uses the preclaim option to lock an area will not wait for an area that is held by another transaction while it holds a lock on an area.
On First Area Access
The incremental mode directs CA IDMS to delay placing a lock on an area until the first statement in the transaction that requires access to the
area
is executed.
You can use the incremental mode to increase database concurrency. A transaction that uses the incremental mode does not place a lock on an area until the area is actually required for processing. This makes the area accessible to other transactions for a longer period of time. In general, if a transaction does not always access every area in its access path, you should assign the incremental mode to those areas that are least likely to be accessed.
Example
Suppose a transaction needs to access three different tables, each of which is stored in a different area:
Table
Area
Acquisition mode
T1
AREA1
Preclaim
T2
AREA2
Incremental
T3
AREA3
Preclaim
Locks would be acquired in the manner shown next:
TRANSACTION A -------------    .    .    . SELECT * FROM T1;    ◄---------------  Locks are placed on both    .                                     AREA1 and AREA3.    .    . SELECT * FROM T2;    ◄---------------  A lock is placed on AREA2.    .    .    . SELECT * FROM T3;    .    .    .
Record Locks
Purpose of Record Locks
Record locks are used within the central version to control concurrent access to individual record occurrences (rows). Occurrence-level record locks (in conjunction with area locks) are used to:
  • Protect against concurrent update of the same record by two or more transactions
  • Prevent record occurrences that are current within one transaction from being updated by another transaction
Implicit record locks
CA IDMS/DB automatically places locks on records accessed by a transaction if the area in which the record resides is readied in any of the following modes:
Area ready mode
Record lock
Shared retrieval on read records
Shared (S) locks
Shared update
Shared (S) locks on read records; exclusive (X) locks on updated records
Protected update
Exclusive (X) locks on updated records
You can use system generation options to inhibit record locking for navigational DML applications, as discussed in 39.4.6, “System Generation Options Affecting Record Locking".
Shared Record Locks
If shared locks are being maintained, CA IDMS/DB places one on each record as it is accessed. Shared locks are also maintained on:
  • The most-recently accessed record of its type (the most-recently accessed row of each table)
  • The most-recently accessed record in each set (the most-recently accessed row of each constraint or index)
  • The most-recently accessed record in each area.
Additional shared locks are maintained on the current row of each updatable cursor open within an SQL transaction.
CA IDMS/DB releases these locks as the transaction accesses different record occurrences. These implicit record locks guarantee the integrity of the currencies used by navigational DML applications and provide the protection necessary for SQL applications executing with an isolation level of cursor stability.
For more information on isolation levels, see 39.2.4, "Ready Modes and SQL Access".
Exclusive Record Locks
If exclusive locks are being maintained, CA IDMS/DB places them on all records altered by a DML or DDL statement until the recovery unit terminates (that is a COMMIT (CONTINUE), ROLLBACK (CONTINUE) or FINISH is issued) or until the transaction abends.
Implicit Page Locks
Implicit locks are used in a special way to control user access to pages for which the amount of available space has been altered. When the available space on a page is changed as a result of an update operation, CA IDMS/DB places a special implicit exclusive lock on the page, allowing retrieval to continue. If a subsequent DML or DDL command from a different transaction requests further modification to available space on that page, the request is delayed until the lock is released (that is, until the recovery unit that caused the lock to be set terminates).
Explicit Record Locks
The navigational programmer can set
explicit record locks
with the DML KEEP command. The KEEP verb or the KEEP option of a FIND or OBTAIN verb places a shared lock on the record occurrence. KEEP with the EXCLUSIVE option places an exclusive lock on the record occurrence. CA IDMS/DB holds explicit record locks until the transaction terminates or a COMMIT ALL statement is executed.
System Generation Options Affecting Record Locking
Two system generation options affect whether CA IDMS/DB maintains record locks for navigational DML transactions. These options are:
Option
Description
RETRIEVAL LOCK/NOLOCK
Specifies whether CA IDMS/DB places shared locks on records in an area readied in SHARED RETRIEVAL
UPDATE LOCK/NOLOCK
Specifies whether CA IDMS/DB places exclusive locks on records updated in an area readied in PROTECTED UPDATE
These system generation parameters affect only navigational DML applications; they do not apply to SQL applications.
Reading Uncommitted Data
If RETRIEVAL NOLOCK is specified, a transaction may read uncommitted data; that is, it may read data that has been updated by another transaction before those changes have been committed or data that has been accessed by a retrieval transaction may be concurrently updated while the retrieval transaction is still active. This may result in inconsistencies in the data processed by the shared retrieval transaction. These inconsistencies may also include transient 11xx abends from the DBMS.
If UPDATE NOLOCK is specified, a transaction updating data in an area readied in PROTECTED UPDATE does not protect transactions readying the area in SHARED RETRIEVAL. As with RETRIEVAL NOLOCK, it is possible for a transaction which has readied the area in SHARED RETRIEVAL to read a record updated by a PROTECTED UPDATE transaction before it has been committed.
Since both options affect the protection afforded shared retrieval transactions, it is typical (though not required) to set both parameters in the same way. In systems in which there is a high volume of updates, you might want to consider specifying LOCK for both.
No inter-CV retrieval protection is provided except for shared areas accessed through members of a data sharing group. If an area is not shared, then regardless of the system lock options in effect, it is possible for a shared retrieval transaction executing in a central version whose area status is retrieval to read uncommitted data updated by another central version.
TRANSIENT RETRIEVAL area status
As an alternative to using system generation parameters to reduce the volume of record locks maintained, consider using a central version's area status of TRANSIENT RETRIEVAL instead. Provided the area is not updated within the central version, a status of transient retrieval can be used to eliminate the locking of records within the area.