Database Access Commands › Navigational DML › Record Locking

Record Locking

Record locks are used to protect the integrity of database records.

Share and Exclusive Locks

Record locks protect object records from concurrent access or update by other run units. Locks can be shared or exclusive:

• Shared record locks allow other run units to access but not update the locked record.
• Exclusive record locks prohibit other run units from accessing the locked record as long as the lock is maintained.

Implicit and Explicit Record Locks

Record locks can be set implicitly by the DC/UCF central version and explicitly by the application developer, as follows:

• Implicit record locks are maintained automatically for every run unit that executes in shared update usage mode. Usage modes are discussed in 'READY' later in this section.
• Explicit record locks are set by means of a KEEP command or the KEEP clause of a FIND/OBTAIN command. FIND/OBTAIN is described later in this section.

  Long-term explicit record locks are shared or exclusive record locks that are maintained across run units. A long-term lock placed on a record restricts other concurrently executing run units from accessing or updating the record until the lock is explicitly released. Subsequent run units in the same CA ADS application that execute from the same terminal can access and update the locked record, and can upgrade or release the long-term lock.

Note: For more information about record locks, see the CA IDMS Database Design Guide.

The following conditions resulting from the use of record locks can cause abnormal termination of an CA ADS application:

• Too many locks— Abnormal termination of an CA ADS application occurs if a run unit tries to generate more record locks than the maximum number specified at DC/UCF system generation. To lessen the possibility of abnormal termination because of too many locks, a COMMIT command can be used to release locks.
• Wait time—Abnormal termination of an CA ADS application occurs if the internal wait time of a run unit exceeds the wait interval specified at DC/UCF system generation.
• Deadlock—Abnormal termination of a run unit occurs when two run units would cause a deadlock by being permitted to wait to set locks. The run-unit that would complete the deadlock terminates, control returns to the issuing task, and a minor code 29 is returned.

  An online application can include logic that is invoked if the run unit is terminated because of a db-key deadlock. In this way, the application can maintain the terminal session and save data previously entered on the screen. The application can then ask the user to resubmit the transaction or automatically restart the run unit, establish currency, and try again.

  If the run unit is automatically restarted, the following steps should be followed:

  1. Rebind the run unit. CA ADS automatically starts a new run unit when it encounters the first functional DML statement.
  2. Reestablish currency. If appropriate currencies are not reestablished before retrying the operation that initially caused the deadlock, a status code of nn06 (no currency established) will be returned.

  Note: For more information about handling the minor code 29, see the CA IDMS Navigational DML Programming Guide.

Checking for Deadlock Conditions

Deadlock conditions can be checked for programmatically by using the ALLOWING clause when autostatus is enabled. The check for a deadlock condition can be made after each service request to the DBMS.

Note: For more information about record contention, see the CA IDMS Database Design Guide.

More information:

Error Handling

COMMIT