事务协调器和事务管理器有什么区别？

Question

事务协调器和事务管理器有什么区别？

我不知道这是否是一个有效的问题，但我一直在阅读这两个术语。

如果它们是不同的东西，IBM 的 Websphere 堆栈中有哪些产品可以完成这两种不同的工作？

Answer 1

像 MSDTC 这样的事务协调器是用于管理分布式事务的服务器。 它保存事务的持久记录并管理与资源管理器的两阶段提交/回滚过程的通信。 它可能会或可能不会集成到事务管理器中。

在 TP 中，“事务管理器”是向“资源管理器”发出提交/回滚请求的东西。 “资源管理器”类似于数据库管理系统，它可以事务性地更改状态。 两阶段提交是一种协议，其中事务管理器验证所有资源管理器都可以保证提交事务（即将日志条目写入持久存储并且没有阻止提交的错误条件），然后建议提交。 然后，在将事务标记为“已提交”之前，它将验证该事务是否已被所有资源管理器提交。

事务协调器是处理此提交过程的系统的一部分。 它可能是也可能不是与事务监视器相同的程序。 事务协调器的一个例子是MS DTC （分布式事务协调器）。 有点有趣，因为在这个架构 ( MTS/COM+ ) 中，它实际上是作为一个单独的进程运行的。

事务管理器或 TP 监视器是应用程序用来控制事务提交/回滚过程的子系统。 它托管应用程序的中间层，并提供用于获取事务 ID 和投票提交/回滚事务的 API。 如果投票只涉及一个进程，这相当于建议提交/回滚。 在 Java 圈子中，这通常称为“应用程序服务器”（或有时在使用 EJB 时称为“Bean 容器”）。 事务管理器的示例是 MS 事务服务（后来称为 COM+ 事务服务）、CICS 和各种 Java 应用程序服务器。

如果您有一个连接池和一个跨多个数据库调用的事务，则事务范围必须与会话和连接状态分离。 对 DBMS 的后续调用可能不会通过同一连接。 因此，我们需要一个单独的事务 ID 来标记对数据库的请求。 然后锁由事务 ID 拥有。

由于与数据库连接分离，提交和回滚必须通过另一个协议从中间层进行带外控制。 这是XA 协议（来自 XOpen 标准）或 OLE 事务协议的作用。

对资源管理器的提交/回滚请求不必来自与托管应用程序的服务器相同的服务器。 事务管理器可以使用单独的事务协调器来管理提交/回滚过程。 这些可以使用诸如TX 之类的协议进行通信。 （交易分界）。 在其他情况下，事务管理器可以使用 XA 等协议直接向资源管理器（数据库）发出提交/回滚指令。 因此，事务协调和管理功能在某种程度上是分开的，并且可能由也可能不会由同一块软件完成。 在 MSDTC 的情况下，它们是分开的，但这不是严格要求的。

将事务协调器移到一个单独的进程中的一个优点是它不会被糟糕的应用程序代码崩溃。 在这种情况下，进程只处理事务提交主机而不处理应用程序 ocde。 其他项目与之通信。 这使得事务协调器非常简单、专注并且能够抵抗应用程序崩溃。 当它被集成到应用服务器中时，应用服务器崩溃可能会中断涉及与应用无关的第三方资源管理器的事务。 将事务协调移动到一个单独的进程的不利方面是由于网络请求而增加了事务提交的延迟。

编辑：我不确定 Websphere 但 IIRC Weblogic 上的事务协调器称为“Weblogic 事务管理器”，事务管理是通过 bean 容器完成的。