Lock Management › Locking Within Central Version › System Generation Options Affecting Record Locking

System Generation Options Affecting Record Locking

Two system generation options affect whether CA IDMS/DB maintains record locks for navigational DML transactions. These options are:

Note: These system generation parameters affect only navigational DML applications; they do not apply to SQL applications.

Reading Uncommitted Data

If RETRIEVAL NOLOCK is specified, a transaction may read uncommitted data; that is, it may read data that has been updated by another transaction before those changes have been committed or data that has been accessed by a retrieval transaction may be concurrently updated while the retrieval transaction is still active. This may result in inconsistencies in the data processed by the shared retrieval transaction. These inconsistencies may also include transient 11xx abends from the DBMS.

If UPDATE NOLOCK is specified, a transaction updating data in an area readied in PROTECTED UPDATE does not protect transactions readying the area in SHARED RETRIEVAL. As with RETRIEVAL NOLOCK, it is possible for a transaction which has readied the area in SHARED RETRIEVAL to read a record updated by a PROTECTED UPDATE transaction before it has been committed.

Since both options affect the protection afforded shared retrieval transactions, it is typical (though not required) to set both parameters in the same way. In systems in which there is a high volume of updates, you might want to consider specifying LOCK for both.

Note: No inter-CV retrieval protection is provided except for shared areas accessed through members of a data sharing group. If an area is not shared, then regardless of the system lock options in effect, it is possible for a shared retrieval transaction executing in a central version whose area status is retrieval to read uncommitted data updated by another central version.

TRANSIENT RETRIEVAL area status

As an alternative to using system generation parameters to reduce the volume of record locks maintained, consider using a central version's area status of TRANSIENT RETRIEVAL instead. Provided the area is not updated within the central version, a status of transient retrieval can be used to eliminate the locking of records within the area.