两阶段提交性能注意事项
当事务集成器 (TI) 组件在事务中执行时，TI 运行时环境会将消息发送到 COM+ 环境中的 Microsoft 分布式事务处理协调器 (DTC) ，在事务上登记自己作为特殊类型的 LU 6.2 资源管理器。 TI 将其数据缓冲区发送到主机并接收回复后，它会调用 SetComplete 方法并将控制权返回到 COM+。 此时，客户端应用程序或其他驱动 TI 的组件可以执行同样包含在同一事务中的其他工作。 当所有资源管理器都进行了更新并发出 SetComplete时，事务的创建者 (自动事务的 COM+ 本身) 将 Commit 方法发送到 DTC。 DTC 将第一阶段 (Prepare) 消息发送到所有资源管理器，包括 TI 运行时环境。 TI 生成 Prepare PS Header SNA 格式中定义的 ，并将其发送到主机。 它会在答复中收到 RequestCommit ，指示主机更新有效且可以提交，并将此信息传递回 DTC。 DTC 从所有资源管理器收集投票，如果一切就绪，它会强制将提交记录写入日志并发送 Committed 消息。 同样，TI 将此转换为 SNA PS Header，接收回复，并将其转换回 DTC。 如果一切按计划进行，DTC 将回滚事务，APPC/LU 6.2 会话将解除分配。
注意
TI 和 AP 都不需要关注 APPC 或 CPI/C SYNCPT 谓词。 “获取 SyncPoint”的决定由事务创建者做出，以 OLE 事务的语义表示，并且涉及事务中的所有参与者，而不仅仅是 TI LU 6.2 分支。 TI 的作用较低;TI 充当 DTC 的资源管理器。 它在 DTC 使用的 COM 接口和主机理解的 SNA 协议之间转换，以执行协议的两个阶段，并使 DTC 能够在第一阶段和第二阶段之间做出提交决策。
从性能的角度来看，保证主机更新的原子性会增加巨大的不可避免的开销。 对于两阶段提交 (2PC) ，还有两个额外的往返消息流流到主机，以及要登记的 Windows 消息流，事务日志记录 (DTC 和主机上) 的强制磁盘写入。 将不需要大量业务逻辑处理的事务与没有 2PC 的同一事务进行比较时，可能需要两倍或更多时间才能完成。
仅当关联的主机事务程序 (TP) 修改必须与 Windows 操作系统上的资源保持一致的任务关键型资源时，才应配置 TI 组件以支持 ACID 事务。 如果 TP 不会修改必须保证一致性的任何资源，请将 TI 组件配置为 “不支持事务”，以便不尝试 2PC。 然后，还可以自由使用 TCP/IP 协议。 TCP/IP 协议不支持 2PC。
永远不应将 TI 组件配置为 “需要新事务”。 这意味着你正在远程管理主机的事务，这会产生创建新事务、登记该事务以及执行与主机的 2PC 交换的开销，但 TI 方法本身将是一个事务。 使 CICS 和 IMS 能够管理自己的事务更高效。 Windows 操作系统上的任何更新都不是该事务的一部分，因此它们将独立提交或回滚。
注意
同一服务器上的其他业务逻辑处理降低了吞吐量限制，从而窃取了部分 CPU。 但是，在总体响应时间预算范围内，成本可能相对较小。