消息流事务

事务描述应用程序执行的一组更新，它们必须一起进行管理。 更新可针对于一个或多个系统。 程序执行的更新由程序执行所在的环境控制，并且可全部完成或不完成。 事务的此属性被称为一致性；事务可具有其他属性：原子数、隔离和持久性。

IBM® App Connect Enterprise 支持事务，并且消息流处理的每段数据都有关联的事务。 在流中的输入节点上接收到输入数据时，将启动消息流事务；此事务将在流完成处理该消息时进行落实，或者在发生错误时进行回滚。

如果流包含多个输入节点，那么在收到输入数据时将针对每个输入节点启动一个事务。 将针对输入节点的每个类型启动一个事务，包括用户定义的输入节点。

消息流中包含的消息流节点根据每个节点定义的功能提供特定消息处理。 执行的处理包括内部工作，您可以通过配置节点属性影响其中一部分。 某些消息流节点执行更多任务，这些任务可能会影响消息流、集成服务器或集成节点外部的系统。

如果外部系统 (例如数据库) 支持落实和回滚概念，并且它可以参与 App Connect Enterprise 事务，那么您可以配置消息流节点，以便它所执行的工作包含在流事务中。 根据消息流节点，您还可以指定是立即落实在支持事务的外部系统中完成的工作，还是在消息流事务完成时落实。

可与消息流交互的许多资源由可参与协调事务的资源管理器控制; 例如，数据库， IBM MQ 消息和队列， CICS， 和 JMS 消息。 其他资源管理器不提供事务支持；例如，HTTP 协议和文件系统。

落实或回滚

如果资源可参与事务，那么您可以进行配置以使其执行的工作仅在消息流完成或节点完成时才进行落实或回滚。 数据库和 IBM MQ 队列是可以通过此方式使用的资源的示例。 如果资源没有事务行为，那么将立即落实其执行的所有工作。 例如，文件和 HTTP 连接不支持事务。

在流成功处理输入消息后，将落实消息流执行的更新。 如果满足以下条件，那么将回滚更新：

  • 流中的节点抛出非输入节点 (例如，节点本身或 TryCatch 节点) 未捕获的异常
  • 未连接输入节点的 Catch 终端
  • 已连接输入节点的 Catch 终端，但连接到 Catch 终端的消息流节点中发生未处理的异常。

在分布式系统上，缺省情况下，消息流事务由 App Connect Enterprise管理。 这些事务也称为局部事务或局部协调事务。 在流完成处理后控制返回到输入节点时，输入节点落实或回滚已执行的操作，已配置为执行自己的落实和回滚或不支持此选项的个别节点除外。

如果消息流访问多个资源，那么可能发生一个错误阻止所有资源落实已执行的所有工作。 App Connect Enterprise 会引发异常，并以由所涉及的传输确定的方式处理异常处理。 例如，从 IBM MQ 队列中读取的报文会恢复到这些队列中，故障报文会发送到通过 HTTP 提交报文的应用程序（因为 HTTP 没有回滚的概念）。 由于这些操作，资源状态可能不一致。

如果消息流访问多个 IBM MQ 队列管理器资源，那么 IBM MQ 资源的缺省落实顺序是消息流使用资源的顺序; 例如，如果 MQInput 节点正在使用与非缺省队列管理器的远程客户机连接来驱动聚集消息流，那么将首先落实 MQInput 节点链接。 并且将落实聚集节点到缺省队列管理器的链路。

但是，如果要确保先落实缺省队列管理器上的资源，那么可以将环境变量 MQSI_COMMIT_DEFAULT_QUEUE_MANAGER_FIRST 设置为任何值并将其导出，或者更新 server.conf.yaml 配置文件中的以下设置：
ResourceManagers:
  MQConnectionManager:
    defaultQMCommitSequence: 59  # Determines the relative order of commit for default MQ links; set to 59 for commit before other queue managers, and 62 for after them.
消息流中使用的资源管理器按优先级顺序落实，标准 IBM MQ 连接 MQCMIT 按优先级 60 执行，并按已描述的使用顺序落实各个队列管理器连接。
  • 如果将 defaultQMCommitSequence 设置为 59，那么会将缺省队列管理器的 MQCMIT 调用移到其他队列管理器的 MQCMIT 调用之前。
  • 如果将 defaultQMCommitSequence 设置为 62，那么会将缺省队列管理器的 MQCMIT 调用置于其他队列管理器的 MQCMIT 调用之后。
  • 从 IBM App Connect Enterprise 12.0.4 开始，远程缺省队列管理器的缺省序列为 59 ，这意味着缺省情况下会首先落实远程缺省管理器。

如果数据和操作保持一致很重要，并在一个或多个操作失败时落实或回滚所有操作，那么可以协调消息流的活动。

协调事务

协调由使用 XA 协议与资源管理器进行交互的外部事务管理器提供。 在消息流结束时（成功或包含错误）输入节点将调用事务管理器。 事务管理器（而非输入节点和集成节点）与相关资源管理器进行交互，以便为每个资源启动正确的操作。 事务管理器以此方式控制的事务被称为全局协调的事务。

在分布式系统上，与集成节点关联的 IBM MQ 队列管理器将执行事务管理器角色，这意味着 App Connect Enterprise 在处理消息时需要访问 IBM MQ 。 队列管理器必须位于本地，并配置为事务管理器。 该消息流中所有其他与 MQ 节点进行交互的队列管理器都将被视为局部协调资源。 有关将 IBM MQ 与 App Connect Enterprise配合使用的更多信息，请参阅 IBM App Connect Enterprise 与 IBM MQ之间的交互。

事务管理器的角色

如果消息流在其所有操作中都成功，那么消息流所执行的操作的结果对于局部事务和全局协调事务都相同。 全局协调事务的优点是能够确保落实所有操作或者不落实任何操作。

采用两阶段落实策略的外部事务管理器支持在落实处理期间一个或多个外部资源管理器临时不可用的情况。 对于业务环境而言，这一潜在的故障小窗口的成本可能很高；外部事务管理器可帮助消除故障窗口的出现。 因此，包含外部事务管理器（包括性能开销）的决策是管理决策，而不是在消息流设计时进行的决策。

外部事务管理器无法避免消息丢失；即使使用事务协调，也必须配置和编写消息流以尽可能处理潜在错误。

要配置全局协调的消息流，还必须设置环境，从而将资源管理器定义到受支持的事务管理器。 在分布式系统上，事务可由 IBM MQ进行协调。

此配置可能要求您更改事务管理器以及分区资源管理器中的设置。

数据库访问方式和锁定

如果想要在同一消息流中包含事务状态为自动的消息流节点以及事务状态为落实的节点（其中节点在同一外部数据库上运行），那么必须使用单独的 ODBC 连接。 对于直至未消息流完成才落实的节点设置一个连接，并对立即落实的节点设置另一个连接。

  • 如事务状态为落实的节点后跟事务状态为自动的节点，那么事务状态为落实的节点将独立于流事务进行落实，而事务状态为自动的节点在流结束是落实。
  • 但是，如果事务状态为自动的节点后跟事务状态为落实的节点，并且不使用单独的 ODBC 连接，那么将发出错误消息 BIP4001，否则事务状态为落实的节点将过早落实自动节点的工作。

Linux 平台Windows 平台UNIX 平台在分布式系统上，个别关系数据库可能不支持此操作方式。

如果对于同一数据源定义了多个 ODBC 连接，那么可能会遇到数据库锁定问题。 特别是，如果事务状态为自动的消息流节点执行诸如 INSERT 或 UPDATE 之类的操作时，会导致数据库对象（例如，表）被锁定，并且当后续节点试图使用不同的 ODBC 连接来访问该数据库对象时，会发生无限锁定（死锁）。

第二个消息流节点等待第一个节点获取的锁定被释放，但是第一个节点在消息流完成前不会落实其操作并释放其锁定。 由于第二个节点等待第一个节点持有的数据库锁定释放，因此流无法完成。

DBMS 自动防死锁例程无法检测到此类情况，这是因为，这两项操作通过使用集成节点间接地相互干扰。

您可以使用以下两个选项之一从而避免此类型的锁定问题：

  • 设计您的消息流，以使未落实的（自动）操作不会锁定后续操作通过不同的 ODBC 连接访问的数据库对象。
  • 配置数据库的锁定超时参数，以使指定时间段过后不会尝试获取锁定。 如果数据库操作由于发生锁定超时而失败，那么将抛出异常，而集成节点将以正常方式处理此异常。

有关特定操作锁定哪些数据库对象、如何配置数据库的锁定超时参数的信息，请参阅您的数据库产品文档。