CICS - 多个用户的更新

Question

如果大约 50 个用户试图更新 DB2 表中的相同字段，CICS 将如何处理这个问题？ 这在 COBOL DB2 程序中是如何处理的？

Answer 1

当 CICS 伪会话程序与 DB/2 交互时，必须注意管理数据完整性 更新数据库， 尤其是当多个 CICS 事务可能试图读取/更新同一个事务时 DB/2 表行几乎同时发生。

以下是对伪对话的常见设计模式的非常简化的解释 CICS 事务（这是 CICS 最常见的交互式编程模式类型）。这个问题的答案： what-are-the-advantages-of-pseudo-conversational-vs-conversational-cics-programm 提供 对伪会话 cics 工作原理的简短概述，您可能需要在继续之前查看此内容...

伪会话 CICS 事务旨在获取其当前运行 来自 COMMAREA 的状态（在事务之间持续存在的一块内存）。保存状态 程序使用 COMMAREA 中的内容来确定下一步需要做什么。然后它执行它，确定下一个状态是什么 应该是，保存新状态和它可能的任何数据 需要“记住” 进入 CICS COMMAREA，然后退出 - 释放所有资源，包括它持有的任何 DB/2 锁。

DB/2 锁是在面对多个竞争选择/更新/插入/删除事务时保持数据库完整性的关键 相同的数据库行。伪会话 CICS 的问题是这些锁在事务启动之间丢失 它从表中获取的数据以及更新表所需的时间。

典型的伪会话 CICS 事务可能经历的状态类似于：

• 初始 - 开始新的交易，要求用户输入关键数据（将下一个状态设置为显示）
• 显示 - 验证在初始状态输入的密钥。从 DB/2 检索相关数据并显示（将下一个状态设置为 Commit）
• Commit - 验证从 Display 状态更改的数据并更新 DB/2（将下一个状态设置为 Initial）

请注意，在显示期间检索数据。 DB/2 在此时获取了一个读锁 是时候防止其他事务在读取行时更新行。取决于 DB/2 和您的 DML 已配置，此锁可能仅在 显示 阶段期间或仅在行正在显示时处于活动状态 取回。在任一情况下， 一旦程序退出，该锁就会丢失。当程序再次重新启动时，它将处于 Commit 状态，准备好 执行适当的 DB/2 更新/插入 DML 以实现对数据库的请求更改。

由于在这些状态转换之间没有持久的 DB/2 锁，因此没有什么可以阻止另一个 事务在第一个事务显示和更新之间访问或更改数据。 这可能导致严重的数据完整性问题。请注意，当事务处于活动状态时，它可能持有 DB/2 锁 有效地防止其他事务读取未提交的更新或更新它的行 是“看着”——但它不能在“对话”的调用之间保持这些。

程序员用来在伪会话 CICS 过程中维护数据完整性的通用机制 交易是拥有所有交易 依靠单个公共可更新资源来充当更新冲突检测器。例如，如果您的数据库 在管理与您的客户相关的数据时，可能有一个通用的唯一键用于识别任何给定的客户。这些 唯一键通常只是一个数字或短字符串（例如 Customer-Id）。 客户数据库的所有表中的所有行都可能使用相同的通用唯一键来识别特定客户（毕竟 这就是钥匙的意义所在）。

创建一个包含两列的 TRANSACTION 表，一列用于 Customer-Id，另一列用于 一些交易唯一标识符，这通常只是交易开始时生成的时间戳（也可以是 一个task-id，它只需要对一个事务来说是唯一的）。将此事务标识符称为 TRANS-KEY。 当进入交易的显示阶段时，交易 第一次拥有 Customer-Id。然后，它使用其 TRANS-KEY 更新此 Customer-Id 的 TRANSACTION 表。两个都得救了 到 COMMAREA。注意这里的更新是只根据Customer-Id做的，会用自己的替换掉当前的TRANS-KEY 独特的价值。 Display 阶段进入，用户输入他们的更改并进入Commit 阶段。此时 事务尝试根据其保存的 Customer-id 和 TRANS-KEY 更新 TRANSACTION 表。如果更新失败交易 “知道”其他人 交易已开始对同一客户进行处理（另一笔交易更改了相同客户 ID 的 TRANS-KEY，因此 当前事务遇到超时或未找到行错误）。 为了保持数据库完整性，当前事务必须退出。它会显示一些 向用户发送消息，通知他们已请求并发更新，并且必须放弃所请求的更新 更新。如果， 另一方面，给定 Customer-id 的 TRANS-KEY 未更改，将采取数据库锁以防止任何 其他事务从更改同一客户 ID 的该行。当前事务可能会更新数据库，因为它知道在它第一次开始操作和提交更新之间没有其他事务查看或更新数据。

使所有这些工作的关键是更新客户数据库的所有事务使用相同的 TRANSACTION 表来检测并发更新尝试。

这里描述的资源锁定机制通常称为“冲突检测”，它只是在整个数据库中保持数据库完整性的众多可能方法之一 伪会话 CICS 事务的过程。关键点是 DB/2 锁被多次取用和丢弃 在事务过程中，它需要 DB/2 锁管理器、CICS Syncpoint 管理器之间的一些“合作” 以及应用程序本身在使用伪会话 CICS 时维护数据库的完整性。

最后，实际更新数据库的事务将是最后一个检索数据的事务 - 所以这个故事的寓意是迟到早完成！

上述讨论并非特定于 COBOL，它适用于所有编程语言，包括 COBOL，用于使用 DB/2 和伪会话 CICS 开发应用程序。

Answer 2

来自 IBM 手册，How CICS connects to DB2：

CICS® DB2® 附件工具随 CICS 一起提供。 CICS DB2 附件工具为 CICS 应用程序提供了在 CICS 环境中操作时对 DB2 数据的访问。因此，CICS 应用程序可以访问 DB2 数据和 CICS 数据。如果发生事务或系统故障，CICS 会协调 DB2 和 CICS 数据的恢复。

CICS DB2 附件工具在 CICS 和 DB2 之间创建了一个整体连接。 CICS 应用程序使用此连接向 DB2 发出命令和请求。 CICS 和DB2 之间的连接可以随时创建或终止，CICS 和DB2 可以独立启动和停止。您可以命名 CICS 连接到的单个 DB2 子系统，或者（如果您有 DB2 版本 7 或更高版本）您可以使用组附加工具让 DB2 选择 DB2 子系统数据共享组的任何活动成员进行连接。您还可以选择 CICS 自动连接和重新连接到 DB2。一个 DB2 系统可以由多个 CICS 系统共享，但每个 CICS 系统一次只能连接到一个 DB2 子系统。

简单来说，将 CICS 视为具有到 DB2 的多个连接池。

当定义 DB2 表时，它是使用页锁定或行锁定来定义的。 （可以用表锁定来定义，但这种情况很少见）。 DB2 数据库引擎将不允许超过一个用户一次更新一个页面或一行，具体取决于锁定级别。

还有读锁来保持表的读一致性。 DB2 将这些读锁称为isolation levels。