Minimizing Contention Among Transactions › Sources of Database Contention › Area Contention

Area Contention

Physical area locks

CA IDMS/DB examines and sets physical area locks whenever an area is opened in an update mode. Physical area locks:

• Prevent concurrent updates by multiple IDMS runtime environments (multiple local database transactions, multiple central versions, or a combination of both)
• Prevent update access to an area that requires rollback of database transactions

Physical locks are handled differently depending on the mode of processing:

• Local mode—As each area is readied in any update mode, the lock is checked. If the lock is set, access to the area is not allowed. If the lock is not set, the local database transaction causes the lock to be set. In the event that the transaction terminates abnormally (that is, without issuing a FINISH), the lock remains set. Further update access or commit processing by subsequent database transactions is prevented until the area is recovered.
• Central version—At system startup, the central version checks the locks in all areas available to the system for update processing. If any lock is set, further access to that area is disallowed (that is, the area is varied offline to the central version). The central version proceeds without the use of that area.

  If the lock is removed after system startup, the operator must vary the area status from offline to online to make the area available to the central version.

Logical area locks

Logical area locks are used by central version to control concurrent access to areas by database transactions running under central version. Logical area locks are derived from the mode in which an area is readied. A logical lock on a database area sometimes causes transactions to wait for database resources. When a transaction cannot ready an area because of a protected or exclusive restriction placed on that area by another transaction, the second transaction is placed in a wait state until the first transaction is finished.

Concurrent area access

The following diagram shows the way in which ready modes and ready options restrict concurrent use of an area by database transactions executing under one central version.

Transaction A readies AREA1 in protected update mode; transaction B readies the area in shared retrieval mode; and transaction C attempts to ready the area in exclusive update mode and is put into a wait state until both transactions A and B terminate. Transactions D and E, attempting to ready the area, must wait until transaction C terminates.