This topic describes locking (enqueuing) functions provided by CICS® (and
access methods) to protect data integrity. There are two forms of
locking:
- The implicit locking functions performed by CICS (or
the access method) whenever your transactions issue a request to change
data. These are described under:
- The explicit enqueuing function that you request by means of an
EXEC CICS command. This is described under Explicit enqueuing (by the application programmer).
Note:
Locking (implicit or explicit) data resources protects
data integrity in the event of a failure, but can affect performance
if several tasks attempt to operate on the same data resource at the
same time. The effect of locking on performance, however, is minimized
by implementing applications with short UOWs, as discussed under
Dividing transactions into units of work.
This section first describes the implicit locking provided while
nonrecoverable files are being updated. It then describes the extended
locking actions when recoverable files are being updated.
Nonrecoverable files
For BDAM files that are nonrecoverable (that is, LOG=NO is specified
in the FCT entry), CICS does not lock records that are
being updated. By default, you get BDAM exclusive control, which operates
on a physical block, is system wide, but lasts only until the update
is complete. If a transaction reads a record for update under BDAM
exclusive control, and the transaction subsequently decides not to
change the data, it must release the BDAM exclusive control. To do
this, issue an EXEC CICS UNLOCK command, which causes CICS to
issue a RELEX macro.
If you don’t want BDAM exclusive control, specify SERVREQ=NOEXCTL
on the file entry in the FCT.
For nonrecoverable VSAM files accessed
in non-RLS mode, VSAM exclusive control locks the control interval
during an update. For nonrecoverable VSAM files accessed in RLS mode,
SMSVSAM locks the record during the update.
Figure 13 illustrates the extent of locking for nonrecoverable
files.
Recoverable files
For VSAM or BDAM files designated as recoverable, the duration
of the locking action is extended as shown in Figure 14.
For VSAM files, the extended locking is on the updated record only,
not the whole control interval.
The extended period of locking is needed to avoid an update committed
by one task being backed out by another. (Consider what could happen
if the nonextended locking action shown in Figure 13 was
used when updating a recoverable file. If task
A abends just after task B has reached syncpoint and has thus committed
its changes, the subsequent backout of task A returns the file to
the state it was in at the beginning of task A, and task B’s committed
update is lost.)
To avoid this problem, whenever a transaction issues a command
that changes a recoverable file (or reads from a recoverable file
prior to update), CICS automatically locks the updated
record until the change is committed (that is, until the end of the UOW).
Thus in the above example, Task B would not be able to access the
record until Task A had committed its change at the end of the UOW.
Hence, it becomes impossible for Task B’s update to be lost by
a backout of Task A. For files opened in non-RLS mode, CICS provides
this locking using the enqueue domain. For files opened in RLS mode,
SMSVSAM provides the locking, and the locks are released at the completion
of the unit of work at the request of CICS.
The file control commands that invoke automatic locking in this
way are:
- READ (for UPDATE)
- WRITE
- DELETE
Notes:
- Enqueuing as described above can lead to transaction
deadlock (see Possibility of transaction deadlock).
- The scope of locks varies according to the access method, the
type of access, and who obtains the lock:
- BDAM exclusive control applies to the physical block
- Non-RLS VSAM exclusive control applies to the control interval
- CICS locks for BDAM (with NOEXCTL specified) apply
to the record only
- CICS locks for non-RLS VSAM apply to the record
only
- SMSVSAM locks for RLS apply to the record only
- VSAM exclusive control. The CICS enqueuing
action on recoverable files opened in non-RLS mode lasts until the
end of the UOW. When a transaction issues a READ UPDATE command,
VSAM's exclusive control of the control interval containing the record
is held only long enough for CICS to
issue an ENQ on the record. CICS then
notifies VSAM to release the exclusive control of the CI, and re-acquires
this only when the task issues a REWRITE (or UNLOCK, DELETE, or SYNCPOINT)
command. Releasing the VSAM exclusive CI lock until the task is ready
to rewrite the record minimises the potential for transaction deadlock
- For recoverable files, do not use unique key alternate indexes
(AIXs) to allocate unique resources (represented by the alternate
key). If you do, backout may fail in the following set of circumstances:
- A task deletes or updates a record (through the base or another
AIX) and the AIX key is changed.
- Before the end of the first task’s UOW, a second task inserts
a new record with the original AIX key, or changes an existing AIX
key to that of the original one.
- The first task fails and backout is attempted.
The backout fails because a duplicate key is detected in the
AIX indicated by message DFHFC4701, with a failure code of X'F0'.
There is no locking on the AIX® key to prevent the second task
taking the key before the end of the first task’s UOW. If there
is an application requirement for this sort of operation, you should
use the CICS enqueue mechanism to reserve the key until
the end of the UOW.
- To ensure that the data being read is up-to-date, the application
program should:
- For files accessed in non-RLS mode, issue a READ UPDATE command
(rather than a simple READ), thus locking the data until the end of
the UOW
- For files accessed in RLS mode, use the consistent read integrity
option.
CICS provides an enqueuing protection facility
for logically recoverable
(as distinct from physically recoverable) transient data destinations
in a similar way to that for recoverable files. There is one minor
difference, however: CICS regards each recoverable destination
as two separate recoverable resources--one for writing and one
for reading.
Transient data control commands that invoke implicit enqueuing
are:
- WRITEQ TD
- READQ TD
- DELETEQ TD
Thus, for example:
- If a task issues a WRITEQ TD command to a particular destination,
the task is enqueued upon that write destination until the end of
the task (or UOW). While the task is thus enqueued:
- Another task attempting to write to the same destination is suspended.
- Another task attempting to read from the same destination is allowed
to read only committed data (not data being
written in a currently incomplete UOW).
- If a task issues a READQ TD command to a particular destination,
the task is enqueued upon that read destination until the end of task
(or UOW). While the task is thus enqueued:
- Another task attempting to read from the same destination is suspended.
- Another task attempting to write to the same destination is allowed
to do so and will itself enqueue on that write destination until end
of task (or UOW).
- If a task issues a DELETEQ TD request, the task is enqueued upon
both the read and the write destinations. While the task is thus enqueued,
no other task can read from, or write to, the queue.
CICS provides the enqueuing protection facility
for recoverable temporary storage queues in a similar way to that
for recoverable files on VSAM data sets. There is one minor difference,
however: CICS enqueuing is not invoked for READQ TS commands,
thereby making it possible for one task to read a temporary storage
queue record while another is updating the same record. To avoid
this, use explicit enqueuing on temporary storage queues where concurrently
executing tasks can read and change queue(s) with the same temporary
storage identifier. (See Explicit enqueuing (by the application programmer).)
Temporary storage control commands that invoke implicit enqueuing
are:
IMS™™ program isolation scheduling ensures that,
when a task accesses a segment by a DL/I database call, it implicitly
enqueues on all segments in the same database record as the accessed
segment. How long it is enqueued depends on the access method being
used:
- Direct methods (HDAM, HIDAM)--If an
ISRT, DLET, or REPL call is issued against a segment, that segment,
with all its child segments (and, for a DLET call, its parent segments
as well), remains enqueued upon until a DL/I TERM call is issued.
The task dequeues from all other segments in the database record
by accessing a segment in a different database record.
- Sequential methods (HSAM, HISAM, SHISAM)--If
the task issues an ISRT, DLET, or REPL call against any segment, the
entire database record remains enqueued upon until a DL/I TERM call
is issued. If no ISRT, DLET, or REPL call is issued, the task dequeues
from the database record by accessing a segment in a different database
record.
The foregoing rules for program isolation scheduling can be overridden
using the ‘Q’ command code in a segment search argument (this
command extends enqueuing to the issue of a DL/I TERM call), or by
using PROCOPT=EXCLUSIVE in the PCB (this macro gives exclusive control
of specified segment types throughout the period that the task has
scheduled the PSB).
CICS provides the
following explicit enqueuing commands:
- EXEC CICS ENQ RESOURCE
- EXEC CICS DEQ RESOURCE
These commands can be useful in certain applications when, for
example, you want to:
- Protect data written into the common work area (CWA), which is
not automatically protected by CICS
- Prevent transaction deadlock by enqueuing on records that might
be updated by more than one task concurrently
- Protect a temporary storage queue from being read and updated
concurrently.
To be effective, however, all transactions must adhere to the same
convention. A transaction that accesses the CWA without using the
agreed ENQ and DEQ commands is not suspended, and protection is violated.
After a task has issued an ENQ RESOURCE(data-area)
command, any other task that issues an ENQ RESOURCE command with the
same data-area parameter is suspended until the task issues a matching
DEQ RESOURCE(data-area) command, or until
the UOW ends.
Note:
Enqueueing on more than one resource concurrently
might create a deadlock between transactions.
The enqueuing and program
isolation scheduling mechanisms, which protect resources against double
updating, can cause a situation known as transaction
deadlock.9
As shown in Figure 15, transaction deadlock
means that two (or more) tasks cannot proceed because each task is
waiting for the release of a resource that is enqueued upon by the
other. (The enqueuing, DL/I program isolation scheduling action, or
VSAM RLS locking action protects resources until the next synchronization
point is reached.)
If transaction deadlock occurs, one task abends and the other proceeds.
- If both deadlocked resources are non-RLS resources, CICS file
control detects the deadlock and abends one of the transactions with
an AFCF abend code.
- If both deadlocked resources are VSAM RLS resources, deadlock
detection is performed by VSAM. If VSAM detects an RLS deadlock condition,
it returns a deadlock exception condition to CICS, causing CICS file
control to abend the transaction with an AFCW abend code. CICS also writes messages and trace entries
that identify the members of the deadlock chain.
Note:
VSAM
cannot detect a cross-resource deadlock (for example, a deadlock arising
from use of RLS and DB2® resources) where another resource
manager is involved. VSAM resolves a cross-resource deadlock when
the timeout period expires, as defined by either the DTIMOUT or FTIMEOUT
parameters, and the waiting request is timed out. In this situation,
VSAM cannot determine whether the timeout is caused by a cross-resource
deadlock, or by a timeout caused by another transaction acquiring
an RLS lock and not releasing it.
- If the resources are both DL/I databases, DL/I itself detects
the potential deadlock as a result of the tasks issuing their scheduling
calls. In this case, DL/I causes CICS to
abend the task that has the least update activity (with abend code
ADCD).
- If both deadlocked resources are CICS resources
(but not both VSAM resources), or one is CICS and
the other DL/I, CICS abends the task whose DTIMOUT
period elapses first. It is possible for both tasks to time out simultaneously.
If neither task has a DTIMOUT period specified, they both remain suspended
indefinitely, unless one of them is canceled by a master terminal
command.
The abended task may then be backed out by dynamic transaction
backout, as described in Transaction backout. (Under certain conditions,
the transaction can be restarted automatically, as described under Abnormal termination of a task. Alternatively, the terminal operator may restart
the abended transaction.)
For more information, see Designing to avoid transaction deadlock.
Transaction deadlock is sometimes known as enqueue deadlock, enqueue interlock,
or deadly embrace.
[[ Contents Previous Page | Next Page Index ]]