问题标签 [2phase-commit]

我试图理解两阶段提交，但我不清楚每个本地站点何时执行其分布式事务的一部分。

在发送准备消息之前是否发生这种情况。那是在两阶段提交 xa 协议甚至运行之前发生吗？

还是每个站点在收到准备消息后执行其部分分布式事务，这意味着准备消息本身也包括要执行的事务查询？

据我了解，在两阶段提交之前甚至需要运行往返通信以将事务发送到每个站点。每个站点都会执行他们的事务部分，当协调器从所有站点获得响应时，它会运行两阶段提交。这将启动准备阶段等。

为什么有必要将准备阶段与两阶段提交之前的执行分开？是否有理由不合并执行和准备阶段，从而减少往返通信成本？

这是我之前的问题的后续。

我有以下要求，需要知道如何使用 Spring JDBCtemplate 实现 2 阶段提交。

1. 应用程序 (JAR) 将作为计划 JOB 独立运行。（无 Web 容器）
2. 我需要连接2个数据库。（数据库 1 和数据库 2）
3. 连接数据库 1 (Oracle)（选择 DATA）并存储在变量中。
4. 连接数据库 2 (postgresql)（更新/插入从数据库 1 收集的数据到数据库 2）。
5. 如果数据库 2 的事务成功，则
6. 连接数据库一并更新特定表中的标志。

请向我推荐示例工作代码或建议替代的快速方法。

问候，米希尔舒克拉。

我有一个EJB在服务器上运行的应用程序，Glassfish它将数据存储在MySQL我称之为全局数据库的数据库中。我有两个确切的远程 Swing 应用程序，它们是EJB's使用RMI. 他们有自己的本地数据库，以防连接丢失。

我的目标是实现两阶段提交协议，即让一个参与者作为协调者，其他人作为参与者。

我能想到的一种方法是使用JMS即跨队列发送消息并使远程客户端侦听这些消息并采取适当的措施来实现。我这样做是在 Swing 应用程序之一的 Buttonclick 上发送消息。问题是，即使我已经实现了困难MessageListener，onMessage()方法也没有收到其他客户端的任何消息。

每个远程客户端都有以下属性集：

这是为了连接到Glassfish服务器并访问我已经配置的connectionFactory和。Queue

是因为只允许在服务器上运行的应用程序而不是远程应用程序接收消息吗？

欢迎任何有关 2 台 PC 拓扑的建议。

我一定遗漏了一些关于 PostgreSQL 和 PREPARE TRANSACTION 的两阶段提交的信息。

以下 SQL ：

给出以下锁：

一旦交易准备好：

锁不见了。

因为在 PREPARE 和 COMMIT 之间发生了小的延迟，另一个查询可能会获得旧版本的记录。

是否有配置设置来避免这种行为，还是设计使然？

提前致谢。

编辑：我在 Windows x64 上使用 PostgreSQL 9.2.2（PostgreSQL 9.2.2，由 Visual C++ build 1600 编译，64 位）

编辑 2：以下是完整的测试用例：

在新会话中发出以下内容：

然后在另一个新会话中：

您将获得旧版本的记录。

我在 Windows 环境中使用 PostgreSQL 9.2。我在使用 MSDTC的 2PC（ 2 阶段提交）环境中。

我有一个客户端应用程序，它在 SERIALIZABLE 隔离级别启动事务，在表中为特定外键值插入新的数据行（列上有一个索引），并投票完成事务（交易已准备好）。事务将由事务协调器提交。

紧接着，在事务之外，同一个客户端向所有行请求这个相同的特定外键值。

因为在前一个事务真正提交之前可能存在延迟，所以 SELECT 子句可能会返回数据的前一个快照。事实上，它确实有时会发生，这是有问题的。当然，应用程序可能会重新设计，但在那之前，我正在寻找锁定解决方案。咨询锁？

我已经在对特定行执行 UPDATE 时解决了这个问题，然后使用 SELECT...FOR SHARE，它运行良好。SELECT 等待事务提交并返回新旧行。

现在我正在尝试为 INSERT 解决它。SELECT...FOR SHARE 不会立即阻止并返回。

这里没有并发问题，因为只有一个客户端处理一组特定的行。我已经知道 MVCC。

任何帮助表示赞赏。

我在 Tomcat 中部署了一个应用程序，其中后端 oracle 和 JPA 作为持久性管理器。现在我们正在引入一个中间数据库（很可能是 SolidDB 或 TimesTen），这将带来 2 阶段提交的额外要求。由于 tomcat 不支持 J2EE，我们将无法使用常规方法。使用 Atomikos 怎么样。有没有其他支持tomcat的事务管理系统。我们的应用程序一天的峰值负载将达到 4000 万条记录。使用 Atomikos 可靠吗？欢迎任何其他建议。

我的问题是这样的：

假设我有一个事务管理器和 2 个资源管理器。

1. TM 告诉 RM 做好准备。
2. RM 承认他们已准备好/投赞成票。
3. TM 告诉 RM 提交。
4. RM 1 提交并确认提交。
5. 由于网络故障，RM 2 永远不会收到提交消息。

在这种情况下，我知道 RM 2 处于等待状态，然后会话在数据库中超时并进入不确定状态。

如果在超过 AbandonTimeout 之前 TM 没有与 RM 重新连接，则该事务被放弃。

我的问题是，当 TM 继续尝试恢复 RM 时，全局事务会发生什么？

TM 在开始尝试恢复时是否向应用程序发送异常？

即使其中一个 RM 从未发送过确认，TM 是否会发回成功消息？

AbandonTimeout 默认为 24​​ 小时。TM 是否将事务保留 24 小时，然后一旦达到超时，就发回异常？

在此链接中2 阶段 提交阶段 2 状态的结束：

1. 协调器向所有群组发送提交消息。
2. 每个队列完成操作，并释放事务期间持有的所有锁和资源。
3. 每个群组向协调员发送确认。
4. 协调器在收到所有确认后完成事务。

那么如果从未收到提交的确认，全局事务会发生什么？

在恢复操作期间，我找不到任何有关解决全局事务的信息。任何帮助，将不胜感激。

谢谢，马特

所有事务管理器（Atomikos、Bitronix、IBM WebSphere TM 等）都将一些“事务日志”保存到文件系统的“tranlogs”文件夹中。

当可怕的事情发生并且服务器宕机时，有时tranlogs会被破坏。他们需要一些手动恢复过程。

有人告诉我，只需清除损坏的 tranlogs 文件夹，我就有可能使参与事务的资源状态不一致。

作为一个“愚蠢”的开发人员，我对简单的概念感到更自在。我想认为分布式事务管理应该类似于常规事务管理：

1. 如果任何一方出现问题（网络、应用程序错误、超时）——我希望整个多资源事务不会在它的任何部分提交。所有剩菜迟早都应该自动清理干净。
2. 如果事务管理器失败（文件系统故障、电源故障）——我希望这个 TM 下的所有事务都被回滚（显然，在数据库超时级别）。
3. 如果我不想进行任何自动 TX 恢复（无论这意味着什么），用于 tranlogs 的文件存储是可选的。

问题

为什么我不能这样想？2PC有什么复杂的？

当我清除损坏的传输日志时，确切的风险是什么？

如果我错了，我真的需要 2PC 文件系统状态的所有混乱。TX 管理器实际上可以以一种简单而丑陋的方式破坏存储状态，您不觉得恶心吗？

我试图了解三阶段提交如何避免阻塞

考虑以下两种失败情况：

场景 1：在第 2 阶段，协调器向所有群组发送 preCommit 消息，并且已从群组 A 之外的所有群组获得确认。网络问题阻止群​​组 A 接收协调器的 preCommit 消息。队列 A 等待 preCommit 消息超时并选择中止。然后协调者和队列 A 都崩溃了。

场景 2：协议到达阶段 3。协调器向队列 A 发送一个 doCommit 消息。但在它可以发送更多的 doCommit 消息之前，协调器崩溃了。群组 A 提交其部分事务然后崩溃。

据我所知，其余队列在场景 1 和场景 2 结束时具有完全相同的状态。因此，当恢复协调员介入时，它如何从剩余队列中找出我们是否处于场景 1 并中止或我们在场景 2 中并提交，从而避免阻塞？