Record locking

 

When a job holds a record lock and another job attempts to retrieve that record for update, the requesting job waits and is removed from active processing.

The requesting job will be active till one of the following events occurs:

• The record lock is released.

• The specified wait time ends.

More than one job can request a record to be locked by another job. When the record lock is released, the first job to request the record receives that record. When waiting for a locked record, specify the wait time in the WAITRCD parameter on the following create, change, or override commands:

• Create Physical File (CRTPF)

• Create Logical File (CRTLF)

• Create Source Physical File (CRTSRCPF)

• Change Physical File (CHGPF)

• Change Logical File (CHGLF)

• Change Source Physical File (CHGSRCPF)

• Override Database File (OVRDBF)

When you specify wait time, consider the following information:

• If you do not specify a value, the program waits the default wait time for the process.

• For commitment definitions with transaction-scoped locks only, the job default wait time can be overridden by a transaction lock-wait time that can be specified on:

  • The xa_open API.

  • A JDBC or JTA interface. Distributed transactions lists these APIs.

• If the record cannot be allocated within the specified time, a notify message is sent to the high-level language program.

• If the wait time for a record is exceeded, the message sent to the job log gives the name of the job holding the locked record that caused the requesting job to wait. If you experience record lock exceptions, you can use the job log to help determine which programs to alter so they will not hold locks for long durations.

Programs keep record locks over long durations for one of the following reasons:

• The record remains locked while the workstation user is considering a change.

• The record lock is part of a long commitment transaction. Consider making smaller transactions so a commit operation can be performed more frequently.

• An undesired lock has occurred. For example, assume that a file is defined as an update file with unique keys, and that the program updates and adds additional records to the file. If the workstation user wants to add a record to the file, the program might attempt to access the record to determine whether the key already exists. If it does, the program informs the workstation user that the request made is not valid. When the record is retrieved from the file, it is locked until it is implicitly released by another read operation to the same file, or until it is explicitly released.

  For more information about how to use each high-level language interface to release record locks, see the appropriate high-level language reference manual. Related information for commitment control has links to high-level language manuals that you can use with commitment control.

  The duration of the lock is much longer if LCKLVL(*ALL) is specified because the record that was retrieved from the file is locked until the next commit or rollback operation. It is not implicitly released by another read operation and cannot be explicitly released.

Another function that can put a lock on a file is the save-while-active function.

 

Parent topic:

How commitment control works with objects

 

Related concepts

JDBC Distributed transactions
Saving your system while it is active

 

Related reference

Related information for commitment control