事务死锁的可能性

用于保护资源免受双重更新的排队和程序隔离调度机制可能会导致称为 事务死锁 的情况。

如 图 1 中所示，事务死锁意味着两个 (或更多) 任务无法继续，因为每个任务都在等待另一个任务排队的资源的释放。 (排队， DL/I 程序隔离调度操作或 VSAM RLS 锁定操作将保护资源，直到到达下一个同步点为止。)
图 1。 事务死锁 (一般化)
此图说明两个任务 (显示为任务 A 和任务 B) 如何同时运行并更新可恢复资源。 顺序如下: 任务 A 更新资源 1 ，同时任务 B 更新资源 2。 在相同的工作单元中继续执行，这意味着仍持有锁定， A 然后尝试更新资源 2 ，而 B 尝试更新资源 1。 结果是死锁，每个任务都等待另一个任务释放其锁定。
如果发生事务死锁，那么一个任务将异常终止，另一个任务将继续执行。
  • 事务死锁检测由 DTIMOUT 事务属性控制。 如果任务在指定的时间间隔内仍处于暂挂 (不活动) 状态 (并且还指定了 SPURGE (YES)) ，那么 CICS® 将启动任务的异常终止。 CICS 提供的镜像事务， CSMI ， CSM1， CSM2， CSM3 和 CSM5 具有缺省设置 DTIMOUT (NO) 和 SPURGE (NO)。
  • 如果两个死锁资源都是 VSAM RLS 资源，那么死锁检测由 VSAM 执行。 如果 VSAM 检测到 RLS 死锁条件，那么它会向 CICS 返回死锁异常条件，从而导致 CICS 文件控制异常终止具有 AFCW 异常终止代码的事务。 CICS 还会写入用于标识死锁链成员的消息和跟踪条目。
    注: VSAM 无法检测涉及另一资源管理器的跨资源死锁 (例如，由于使用 RLS 和 DB2® 资源而产生的死锁)。 当超时时间段到期 (由 DTIMOUT 或 FTIMEOUT 参数定义) 并且等待请求超时时， VSAM 将解决跨资源死锁。 在这种情况下， VSAM 无法确定超时是由跨资源死锁导致，还是由另一个事务获取 RLS 锁定而未释放该锁定所导致的超时。
  • 如果资源都是 DL/I 数据库，那么 DL/I 本身会检测由于任务发出其调度调用而导致的潜在死锁。 在这种情况下， DL/I 会导致 CICS 异常终止具有最少更新活动的任务 (异常终止代码为 ADCD)。
  • 如果两个死锁资源都是 CICS 资源 (但并非同时是 VSAM 资源) ，或者其中一个是 CICS 和另一个 DL/I ，那么 CICS 会异常终止其 DTIMOUT 时间段先经过的任务。 这两个任务都有可能同时超时。 如果这两个任务都没有指定 DTIMOUT 时间段，那么它们都将无限期暂挂，除非其中一个任务被主终端命令取消。

然后，可以通过动态事务回退来回退异常结束的任务，如 事务回退 中所述。 (在某些情况下，可以自动重新启动事务，如 事务回退 中所述。 或者，终端操作员可以重新启动异常结束的事务。)

有关更多信息，请参阅 设计以避免事务死锁。