When a transaction locks a resource, that resource is usually occupied until COMMIT or ROLLBACK occurs. For example, because the EX mode is in effect while a locked resource (row or page) is being updated, all other transactions for the resource being updated must wait until COMMIT or ROLLBACK is executed. However, if the UNTIL DISCONNECT option is specified in the LOCK statement, the lock on the resource is retained until either the resource is disconnected or the transaction is committed after the table is deleted.

When row deletion is executed, the lock is maintained until the transaction is completed. However, because the row ends up being deleted from the database, retrieval processing in other transactions does not wait for lock-release in the row being deleted.

Once a resource is locked, that resource is usually not released until COMMIT or ROLLBACK occurs. When an SQL statement with WITHOUT LOCK specified is used for retrieval, however, the lock is released from a locked resource (row or page) as soon as that resource has been referenced. When an SQL statement with WITHOUT LOCK NOWAIT specified is used for retrieval, even tables and rows that have been locked in EX mode by another transaction can be referenced as if they were not locked, except when a logical file is referenced. However, a table cannot be referenced if it is being accessed by the pdload or pdrorg command. For details about the pdload and pdrorg commands, see the HiRDB Version 8 Command Reference manual.

In retrieval using an SQL statement with WITHOUT LOCK NOWAIT specified, referencing is allowed even during updating. Therefore, care must be taken, because the result of the referencing might not be the same as the result after the updating.