Minimizing Contention Among Transactions › Sources of Database Contention › Entity Occurrence Contention

Entity Occurrence Contention

Record locks

CA IDMS/DB sets record locks on entity occurrences accessed by transactions operating under the central version. Record locks are never maintained for transactions operating in local mode, since concurrent update is prevented by physical area locks.

Locks can be set implicitly by the central version or explicitly by the programmer, as described below:

• Implicit record locks are maintained automatically by the central version for every transaction running in shared update mode. They are optionally maintained in shared retrieval and protected update mode, according to your specifications at system generation.
• Explicit record locks, set by the programmer using navigational DML, are used to maintain record locks that would otherwise be released following a change in currency.

  They are never maintained for areas whose status is transient retrieval or for database transactions executing with an isolation level of transient retrieval.

Functions

Record locks perform four functions:

• Protect against concurrent update of the same entity occurrence by two or more transactions
• Protect transactions from reading uncommitted updates made by another transaction
• Protect entity occurrences that are current of one transaction from being updated by another transaction
• Allow one transaction to selectively protect any entity from access or update by another transaction

Increased contention

Record locks can sometimes increase contention among programs that require access to database resources. In some instances, conditions that result from the use of record locks can even cause abnormal termination of transactions executing under the central version. The following conditions can occur:

• Too many locks. If resource limits for locks are established and a transaction tries to generate more locks than the limit, the system might terminate the transaction, depending on your specifications at system generation. If resource limits for locks were not established, the system will continue processing, but processing performance might be degraded.
• Excessive wait time. If a transaction, while attempting to set a record lock, is made to wait for another transaction to terminate (or to release a lock on an entity), the first transaction waits only as long as the interval specified at system generation before abending. When a transaction exceeds the internal wait time, the system will terminate the transaction.
• Deadlock situation. If two transactions are in a deadlock, one of the transactions is aborted. A deadlock occurs when two transactions wait on each other for access to the same resource(s). For example, if both transaction A and transaction B read the same entity occurrence, each acquires a shared record lock on the occurrence. If transaction A then tries to update the entity occurrence, it will wait until transaction B releases its lock. If transaction B tries to update the occurrence, it will wait on transaction A. Transactions A and B are in a deadlock situation.

  CA IDMS/DB resolves this potential bottleneck by aborting and rolling back one of the transactions. By default, the transaction chosen is the most recently begun transaction with the lowest priority.