问题标签 [distributed-transactions]

我有一个涉及多台机器、消息队列和事务的问题。因此，例如，用户点击网页，点击会向另一台机器发送一条消息，该机器将付款添加到用户的帐户中。每秒可能有数千次点击。事务的所有方面都应该是容错的。

我以前从来没有处理过这样的事情，但是一点阅读表明这是一个众所周知的问题。

所以我的问题。我是否正确假设这样做的安全方法是使用两阶段提交，但协议是阻塞的，所以我不会获得所需的性能？我通常编写 Ruby，但似乎像 Redis 这样的 DB 和像 Rescue、RabbitMQ 等这样的消息队列系统并没有真正帮助我 - 即使我实现了某种两阶段提交，如果 redis 崩溃，数据也会丢失，因为它本质上只是内存。

所有这一切都让我看到了 erlang 和 scala——但在我涉足并开始学习一门新语言之前，我真的很想更好地理解这是否值得付出努力。具体来说，我是否正确地认为，由于它们的并行处理能力，这些语言是实现像两阶段提交这样的阻塞协议的更好选择，还是我感到困惑？如果是的话，是否有任何理由选择一个而不是另一个（特别是在这种情况下 - 我知道有很多线程和博客更普遍地比较了两者）

为交叉发布道歉 - 这是第一次发布到堆栈交换，但我已经添加到问题中，这个版本可能更适合这里

使用 Web 服务进行分布式事务的一般方法是什么？假设我有一个应用程序/服务在某种全局事务中与其他两个 Web 服务进行对话。我不太确定在这种情况下两阶段提交是如何工作的。

我有一个应用程序，它使用自己的数据库，还通过基于 XML 的 http post requests/responses 与远程会计系统一起工作。我可以发布借记和贷记 http 发布请求。

当一些用户玩游戏时，我必须给他一些赌注，如果他赢了，我必须借记赢额。由于它是http协议，我实现了一些超时重试功能，但是我想问一下当http请求很好并且我得到响应时如何处理这种情况，但是在那之后我身边发生了一些事情？它就像分布式事务案例，但不一样:(...

一些伪代码更清楚：

这段代码中的问题是： 1) 首先，如果persistOutcome(..) 失败并且在catch 子句中调用cancelStake，它可能无法发送取消请求（即使它有重试算法）。2) 同样适用于第二个 catch 块。

请针对这种情况提出最佳做法。

我正在尝试使用 Terracotta Ehcache（开源）对分布式事务内存进行一些基准测试。我在理解它与 JTA 的工作时遇到了一些问题。在代码中，我发现对分布式事务感兴趣的缓存将自己作为具有 JTA 的资源登记为 JTA 稍后在其上执行两阶段提交的资源。

我的问题是，如果只有一个缓存被列为资源，JTA 将如何能够在分布式设置中自动更新所有其他缓存？我们没有将其他缓存引用传递给 JTA，因此不会对它们进行原子更新。我觉得，我在这里遗漏了一些字符串，谁能解释它是如何工作的？我也是 J2EE 的新手，我是否遗漏了一些允许将其他缓存自动引用传递给 JTA 的 J2EE 概念？

有两台服务器在 WCF 上运行一些服务。所有服务都使用共享数据库。所有服务都使用传输 net.tcp 和允许的事务流

开始使用 TransactionScope 后出现问题：第一个方法成功创建用户第二个成功获取他的配置文件

但第三种方法失败，错误用户未在数据库中找到

但是这样的场景：

工作正常，但不适合我的任务；

问题是在服务器A上创建的本地事务在服务器B上不可见。有人知道如何解决这个问题；

我想将记录从一个数据库移动到另一个位于不同机器上的数据库。记录应该从第一个数据库中删除并自动插入到第二个数据库中。

我们可以使用 xa 吗？我相信 xa 使用 2 阶段提交算法，该算法需要对资源进行阻塞锁定

目标数据库是 EIS 数据库，因此应锁定最短时间。

我有一个与多个数据库和一些自定义服务交互的应用程序。对于某些操作，我需要类似事务的行为，其中一组更改要么跨所有数据库/服务提交，要么在发生错误时全部回滚。

X/Open 组的 XA 标准和 Java JTA 似乎使用两阶段提交过程准确地解决了这个问题。一些数据库（mySQL、Postgres、Oracle）支持这些接口，但我感觉它们不经常使用或流行度下降。真的吗？如果是这样，为什么？

我知道 mySQL 上的 XA 存在一些与复制相关的问题。此外，XA 事务可能会明显变慢。XA 不受欢迎/不常见还有其他原因吗？

是否有一个实用程序可以提供 2 个机器名称并确定它们是否配置正确以处理来回事务？

（如果这对于另一个 Stack Exchange 站点来说是一个更好的问题，请提出建议）

在将 NHibernate 与分布式事务一起使用时，我们遇到了问题。

考虑以下代码段：

有时，当服务器处于极端负载下时，我们会看到以下内容：

1. 使用cmd.ExecuteNonQuery执行的查询被选为死锁牺牲品（我们可以在 SQL Profiler 中看到），但没有引发异常。
2. session.Save失败并显示错误消息“该操作对事务状态无效。”
3. 此后每次执行此代码时，session.BeginTransaction都会失败。前几次，内部异常会有所不同（有时是应该在步骤 1 中引发的死锁异常）。最终它稳定到“服务器未能恢复事务。描述：3800000177”。或“不允许启动新请求，因为它应该带有有效的事务描述符。”

如果不理会，应用程序最终会（在几秒钟或几分钟后）从这种情况中恢复。

为什么第一步没有报死锁异常？如果我们不能解决这个问题，那么我们如何防止我们的应用程序暂时变得不可用呢？

该问题已在以下环境中重现

• Windows 7 x64 和 Windows Server 2003 x86
• SQL Server 2005 和 2008
• .NET 4.0 和 3.5
• NHibernate 3.2、3.1 和 2.1.2

我创建了一个测试夹具，它有时会为我们重现该问题。可在此处获得：http ://wikiupload.com/EWJIGAECG9SQDMZ

我正在处理一个与 NHibernate 和 WCF 服务中的分布式事务相关的奇怪问题。有关更多详细信息，请参阅NHibernate 和分布式事务导致“服务器无法恢复事务”的死锁。

似乎可以解决我的问题的一件事是使用 NHibernate 的 AdoNetTransactionFactory，而不是 AdoNetWithDistributedTransactionsFactory。

我相信 AdoNetWithDistributedTransactionsFactory 与使 NHibernate 的二级缓存机制正常工作有关，但我们没有使用它。将 AdoNetTransactionFactory 与分布式事务一起使用还存在哪些（如果有）其他问题？

谢谢你的时间！