事务协调器和事务管理器之间有什么区别？
我不知道这是否是一个有效的问题，但我一直在阅读这两个术语。
如果它们不同，IBM Websphere堆栈中可以执行这两个不同工作的产品是什么？
答案 0 :(得分：6)
像MSDTC这样的Trasaction Coordinator是一个用于管理分布式事务的服务器。它保存事务的持久记录，并管理与资源管理器的两阶段提交/回滚过程的通信。它可能会也可能不会集成到事务管理器中。
在TP-speak中，“Transaction Manager”是向“资源管理器”发出提交/回滚请求的内容。 “资源管理器”类似于数据库管理系统，它在事务上进行状态更改。两阶段提交是一种协议，其中事务管理器验证所有资源管理器可以保证提交事务（即，将日志条目写入持久存储并且没有会阻止提交的错误条件），然后建议提交。然后，在将事务标记为“已提交”之前，它将验证所有资源管理器是否已提交事务。
事务协调器是处理此提交过程的系统的一部分。它可能与事务监视器相同也可能不同。事务协调器的示例是MS DTC（分布式事务协调器）。这有点令人感兴趣，因为在这个架构（MTS/COM+）中它实际上作为一个单独的过程运行。
事务管理器或TP监视器是应用程序用来控制事务提交/回滚过程的子系统。它托管应用程序的中间层，并提供用于获取事务ID和投票以提交/回滚事务的API。如果投票中只涉及一个进程，则这相当于建议提交/回滚。在Java圈子中，这通常被称为“应用程序服务器”（或者在使用EJB时有时称为“Bean容器”）。事务管理器的示例是MS Transaction Services（以后称为COM + Transaction Services），CICS和各种Java应用程序服务器。
如果您有一个连接池和一个跨越多个数据库调用的事务，那么事务范围必须与会话和连接状态分开。对DBMS的后续调用可能不是通过相同的连接。因此，我们需要一个单独的事务ID，可用于标记对数据库的请求。然后，锁将由交易ID拥有。
由于与数据库连接的分离，必须通过另一个协议从中间层带外控制提交和回滚。这是XA protocol（来自XOpen标准）或OLE事务协议的角色。
对资源管理器的提交/回滚请求不必来自托管应用程序的服务器。事务管理器可以使用单独的事务协调器来管理提交/回滚过程。这些可以使用诸如TX.之类的协议进行通信。在其他情况下，事务管理器可以使用诸如XA之类的协议直接向资源管理器（数据库）发出提交/回滚指令。因此，交易协调和管理功能在某种程度上是分开的，并且可以或可以不由同一软件完成。在MSDTC的情况下，它们是分开的，但这不是严格要求的。
将事务协调器移出到一个单独的进程中的一个优点是它不会因为错误的应用程序代码而崩溃。在这种情况下，进程仅处理事务提交主机没有应用程序ocde。其他项目与之沟通。这使得事务协调器非常简单，集中并且可以抵抗应用程序崩溃。在将其集成到应用程序服务器中的情况下，应用程序服务器崩溃可能会导致涉及与应用程序无关的第三方资源管理器的事务处理。将事务协调转移到单独进程的缺点是由于网络请求导致事务提交的延迟增加。
编辑：我不确定Websphere，但是IIRC，Weblogic上的事务协调员称为“Weblogic事务管理器”，事务管理是通过bean容器完成的。