Locked objects
Jobs and threads use objects to process work.
Because more than one piece of work is processing at a time, a lock is put on an object so that data integrity is retained. Locked objects are system objects used by jobs and threads to process work. After the job or thread is finished running, the object is unlocked and ready to be used to process more work. Depending on the lock request type used, locking an object permits only one user to use an object at a time. For example, if two or more users tried to change an object at the same time, the changes to the object by the second user is locked out until the first user finished updating the object. With the use of lock holders, a user can see what currently has a lock or is currently waiting on a lock for an object.
Scope specifies whether the lock is associated with a job, a thread, or a lock space. Scope also defines how long the lock will be available and what lock request type and conflict rules the object has on it.
Lock request types are different levels of access that a job, thread or lock space can use to an object that is locked. For example, a lock exclusive, no read lock type is used if an object is being changed or deleted on the system. This lock request type does not allow anyone to use the object, nor does it allow anyone to read the object.
The different lock request types are:
- Exclusive - No read
- The object is reserved for exclusive use. However, if the object is locked by any lock request type, you cannot obtain exclusive use of the object. This lock state is appropriate when a user does not want any other user to have access to the object until the function being performed is complete.
- Exclusive-Read
- The object can only be shared with the shared-read lock request type. This lock is appropriate when a user wants to prevent other users from performing any operation other than a read.
- Shared-Update
- The object can be shared with either the shared-read or shared-update lock request type. That is, another user can request either a shared-read lock state or a shared-update lock state for the same object. This lock state is appropriate when a user intends to change an object but wants to allow other users to read or change the same object.
- Shared-No update
- The object can be shared with only share - no update, and shared-read lock request types. This lock state is appropriate when a user does not intend to change an object but wants to ensure that no other user changes the object.
- Shared-Read
- The object can be shared with all lock requests other than exclusive - no read. That is, another user can request an exclusive-read, shared-update, shared-read, or shared-no update lock state.
The lock status tells the state of the lock request. The different lock statuses are:
- Held: The lock request has been fulfilled and the job, thread or lock space is holding the lock.
- Waiting: The job or thread is waiting to obtain the lock.
- Requested: The job or thread has requested the lock.
Lock holders are the jobs, threads and lock spaces that are currently holding a lock or are waiting for a lock on a specific locked object.
Parent topic:
Job characteristics