Database Locks

Database locks control concurrent access to database resources: areas or individual records and rows. Locks are used to ensure that applications only see committed changes. CPU is consumed to acquire locks and storage is consumed in recording them. The greater the number of locks held concurrently, the greater the amount of storage needed.
idms
Database locks control concurrent access to database resources: areas or individual records and rows. Locks are used to ensure that applications only see committed changes. CPU is consumed to acquire locks and storage is consumed in recording them. The greater the number of locks held concurrently, the greater the amount of storage needed.
For more information about database locking, see the
CA IDMS Database Administration section
.
Locking Related Parameters
The following SYSTEM statement parameters are related to database locking:
  • RETRIEVAL LOCK/NOLOCK controls whether record locks are acquired for areas readied in shared retrieval.
  • UPDATE LOCK/NOLOCK controls whether record locks are acquired for areas readied in protected update.
  • SYSLOCKS estimates of the maximum number of database locks that will be held at any time.
  • LOCK LIMIT specifies the maximum number of database locks that can be concurrently held by a transaction.
Controlling Record Locking for the System
The RETRIEVAL and UPDATE parameters control whether record locks are acquired for areas readied in certain modes. By specifying NOLOCK, you reduce the number of locks acquired, but expose retrieval applications to the possibility of accessing modified records whose changes haven't been committed.
For more information about setting these options, see the
CA IDMS Database Administration section
.
Estimating Maximum Locks for the System
The SYSLOCKS parameter provides an estimate of the maximum number of locks held concurrently. It is used in conjunction with MAX TASKS and the number of LTERMS defined to the system to calculate the amount of operating system storage acquired at startup to hold lock-related information. If more storage is needed because of a spike in the number of concurrently held locks, additional storage will be acquired from the storage pool and freed when no longer needed. Although this process allows the system to continue to service lock requests, it costs additional CPU resources to acquire and free the storage and it could lead to fragmentation of the storage pool or short-on-storage conditions. Consequently, it is important to provide a realistic value for the SYSLOCKS parameter.
The best way to determine a value for this parameter is through trial and error. Start with a value from another system that executes a similar mix of transactions or accept the system generation default value. After executing a typical work load, use either LOCKMON or DCMT DISPLAY LOCK STATISTICS to determine whether secondary lock storage was acquired. If secondary storage was acquired frequently, increase the SYSLOCKS value. Ideally, you want to avoid any overflow storage acquisitions; however, infrequent acquisitions may be acceptable.
Limiting Locks Acquired by Task
You can limit the number of locks acquired by tasks on a task-by-task basis or for all tasks within a system. You use the LOCK LIMIT clause of the SYSTEM statement to limit locks set by all tasks within a system. You use the LOCK LIMIT clause of the TASK statement to override the system limit for a specific task.