Run Units, Locks, and Database Transactions › Record Locks

Record Locks

In general, record locks prevent concurrent retrieval and update by separate run units operating under the same central version. This statement does not apply when:

• Run units operate in local mode-concurrent update of record occurrences is prevented by physical area locks.
• RETRIEVAL NOLOCK has been specified in system generation - the system does not maintain locks for retrieval run units.
• Run units share a transaction with other database sessions; all sharing sessions can concurrently retrieve and update the same data.

Exclusive Lock

An exclusive lock indicates that no other run unit can access the designated record occurrence in any way. Only one run unit at a time can place an exclusive lock on a record occurrence. A run unit can place an exclusive lock on a record occurrence only if that occurrence has not been assigned any locks (shared or exclusive) by another run unit. A run unit that tries to place an exclusive lock on an occurrence that already has been locked must wait until all other locks on the occurrence are released.

Shared Lock

A shared lock indicates that other run units can retrieve the designated record occurrence but cannot update it. Any number of run units can place a shared lock on a record occurrence. A run unit that tries to place a shared lock on an occurrence for which an exclusive lock is already held must wait until the exclusive lock is released.

Notify Lock

A notify lock is used in the online environment to monitor database access to a specified record occurrence.

For more information on notify locks, see Maintaining Data Integrity in the Online Environment.

Implicit and Explicit Locks

Record locks can be set implicitly by the central version or you can set them explicitly by coding the DML KEEP function in the program.

Implicit Locks

Implicit locks are maintained automatically by the central version for every run unit accessing the database in shared update usage mode. The DBA can also specify that implicit locks be maintained for run units accessing the database in shared retrieval or protected update usage mode.

For further details about usage modes, see Area Usage Modes.

Types of Implicit Lock

Implicit locks can be shared or exclusive, as follows:

• The central version places implicit shared locks on the record occurrences that are current of run unit, record, set, and area. These locks remain in effect until the record occurrences are no longer current, thereby preventing concurrently executing run units from updating the same record.
• The central version places an implicit exclusive lock on every record occurrence that is modified by a DML statement (STORE, MODIFY, ERASE, CONNECT, or DISCONNECT). Additionally, the central version sets implicit exclusive locks for:
  • The next and prior record occurrences for all sets in which the record's participation has changed
  • Each database page on which the amount of space has been altered as the result of a STORE, MODIFY, or ERASE statement
  • The central version maintains implicit exclusive locks for the duration of the database transaction to prevent concurrently executing run units that are maintaining locks from accessing modified records that might have to be rolled back because of an error later in the program.

For more information on the implicit locks acquired by the DBMS, see Implicit Record Locks.

Explicit Locks

Explicit locks, which you set in your program, maintain record locks that would otherwise be released after a change in currency. The KEEP statement and the KEEP clause of the FIND/OBTAIN statement are used to set explicit shared and exclusive locks.

For more information about setting explicit locks, see Locking Records.

Managing Record Locks

Accumulating a large number of implicit or explicit record locks during a database transaction hinders system performance. You can maintain efficient database transactions by regularly issuing the DML COMMIT statement (described later in this chapter).

Additionally, certain conditions that result from the use of record locks ca CAuse abnormal termination of run units executing under the central version:

• Exceeded wait time-A run unit waiting to set a lock on a record that is currently locked by another transaction abends if it exceeds the internal wait interval specified at central version generation. When this happens, the central version rolls back the database transaction and returns a value of nn69 to the ERROR-STATUS field in the IDMS communications block.
• Deadlock-If two or more run units would cause a deadlock were they all permitted to wait, one of them is aborted to resolve the deadlock.

  When a run unit is terminated because of a potential deadlock, the central version rolls back the database transaction, returns a value of nn29 to the ERROR-STATUS field in the IDMS communications block, and releases all locks held by the aborted run unit.

Deadlock Example

The following sequence of figures shows a typical deadlock situation:

• Run unit A and run unit B have placed shared locks (implicitly or explicitly) on the Bower EMPLOYEE record occurrence and the Bank EMPLOYEE record occurrence respectively; neither of these locks can be released until processing is complete.

┌────────────────────────┬────────────────────────┐
│                        │                        │
│       Locks held       │       Wait state       │
├────────────────────────┼────────────────────────┤
│                                                 │
│                        │                        │
│   A - Bower                                     │
│   B - Bank             │                        │
│                                                 │
│                        │                        │
│                                                 │
│                        │                        │
│                                                 │
├────────────────────────┴────────────────────────┤
│                                                 │
│  ┌──────────────────┐     ┌──────────────────┐  │
│  │     Run unit     │     │    Run unit      │  │
│  │        A         │     │       B          │  │
│  │                  │     │                  │  │
│  │  ┌─────────────┐ │     │  ┌────────────┐  │  │
│  │  │  Executing  │ │     │  │  Executing │  │  │
│  │  └─────────────┘ │     │  └────────────┘  │  │
│  └──────────────────┘     └──────────────────┘  │
│                                                 │
└─────────────────────────────────────────────────┘

• Run unit A tries to place an exclusive lock on the Bank record (locked by run unit B); it is placed in a wait state.

┌────────────────────────┬────────────────────────┐
│                        │                        │
│       Locks held       │       Wait state       │
├────────────────────────┼────────────────────────┤
│                                                 │
│                        │                        │
│   A - Bower                A - Bank             │
│   B - Bank             │                        │
│                                                 │
│                        │                        │
│                                                 │
│                        │                        │
│                                                 │
├────────────────────────┴────────────────────────┤
│                                                 │
│  ┌──────────────────┐     ┌──────────────────┐  │
│  │     Run Unit     │     │    Run Unit      │  │
│  │        A         │     │       B          │  │
│  │                  │     │                  │  │
│  │  ┌─────────────┐ │     │  ┌────────────┐  │  │
│  │  │  Waiting    │ │     │  │  Executing │  │  │
│  │  └─────────────┘ │     │  └────────────┘  │  │
│  └──────────────────┘     └──────────────────┘  │
│                                                 │
└─────────────────────────────────────────────────┘

• Run unit B then attempts to place an exclusive lock on the Bower record (locked by run unit A) and deadlock results.

┌────────────────────────┬────────────────────────┐
│                        │                        │
│       Locks held       │       Wait state       │
├────────────────────────┼────────────────────────┤
│                                                 │
│                        │                        │
│   A - Bower                   A - Bank          │
│   B - Bank             │      B - Bower         │
│                                                 │
│                        │                        │
│                                                 │
│                        │                        │
│                                                 │
├────────────────────────┴────────────────────────┤
│                                                 │
│                                                 │
│  ┌──────────────────┐     ┌──────────────────┐  │
│  │     Run Unit     │     │    Run Unit      │  │
│  │        A         │     │       B          │  │
│  │                  │     │                  │  │
│  │  ┌─────────────┐ │     │  ┌─────────────┐ │  │
│  │  │   Waiting   │ │     │  │   Waiting   │ │  │
│  │  └─────────────┘ │     │  └─────────────┘ │  │
│  │                  │     │                  │  │
│  └──────────────────┘     └──────────────────┘  │
└─────────────────────────────────────────────────┘

• CA IDMS automatically resolves the deadlock by forcing one of the run units to be rolled back. In general, the younger of the two run units will become the victim unless the issuing task has a higher priority than that of the other issuing task involved in the deadlock.

For more information about deadlock detection and processing, see the CA IDMS Database Administration Guide.