Concurrency and Transaction Size

PROIV record-locking behaviour for non-recoverable files is as follows:

When reading a record without write-intent (typically in Lookup Mode) PROIV does not lock the record. PROIV will read the record even if it is locked by another user.
When PROIV reads a record with write-intent, an exclusive lock is acquired on that record if it exists.
When PROIV writes a record or an intended write is cancelled, any lock on that record is released.

This behaviour is preserved for recoverable files with the exception that locks cannot be released until the end of a transaction. All records locked by PROIV in recoverable files thus remain locked until the next commit or rollback. The default configuration of some DBMSs may not permit reading without lock; however, this can usually be resolved by setting suitable configuration options externally to PROIV. behaviour of non-recoverable files is not affected by the use of recoverable files (and vice versa).

Where no locking occurs for reads performed without write-intent, transactions will typically have an uncommitted-read isolation level. A shortcoming of uncommitted-read isolation is that a transaction 'A' can read a record that has been created or modified by another transaction 'B' before transaction 'B' has completed. If transaction 'B' is now rolled back, transaction 'A' may have acted on information that was never committed to the database. Applications for which this is a problem need either to run with a greater level of transaction isolation or to read with explicit write-intent.

A transaction that modifies recoverable files extensively can acquire many concurrent locks. Application design should attempt to avoid transactions that cause excessive locking. One published guideline suggests 500 records as a reasonable limit on the number of updates that should be made by a single transaction. A balance needs to be struck between transaction size and transaction processing overhead. Making transactions unnecessarily small can result in performance degradation simply because of the work involved in terminating more transactions. It is possible to reduce transaction size using the COMMIT() statement provided that attention is paid to issues of read and write currency. (See Using Explicit Commit and Rollback, page 158).

When reducing the size of transactions, bear in mind that the purpose of transaction processing is to ensure application data can be recovered to a consistent state from where the application can reliably continue to be used. After recovery from a system or process failure, application data will be restored to its state immediately following the last completed transactions, because transactions are units of recovery. If this state reflects partial completion of some procedure that cannot readily be continued or restarted, transaction processing will be of reduced value.

A file system or DBMS may have a limit on the maximum number of record-level locks supported. This limit may apply to a whole system or on a per-process basis and will vary from one file system to the next. Some DBMSs automatically escalate multiple record-level locks to a file-level lock when some threshold number of record locks is reached. Transactions that acquire many locks or cause lock escalation can reduce system throughput and efficiency and have an increased probability of deadlock. Explicit file-level locking in PROIV is not permitted.

A filesystem/DBMS may not provide deadlock detection, although some provide a timeout facility as a substitute. For these mechanisms to work, where available, a PROIV process must wait for locks under the control of the filesystem or DBMS rather than repeatedly retrying an operation that requires a lock. While under filesystem or DBMS control, the process may not be able to issue messages informing the user that it is waiting and may not be able to respond to the Break key.

Comment on this topic

Topic ID: 720038