每个多个数据库连接都有一个事务什么时候有意义？答案

【问题标题】：When does it make sense to have a single transaction per multiple database connections?每个多个数据库连接都有一个事务什么时候有意义？
【发布时间】：2011-01-10 20:08:13
【问题描述】：

谁能帮我看看在什么样的场景下拥有一个共享数据库事务和多个连接是有意义的？谢谢。

【问题讨论】：

标签： sql-server database ado.net distributed-transactions

【解决方案1】：

如果您的意思是多个数据库都在一个事务中更新，那么您可以为原子性执行此操作 - http://en.wikipedia.org/wiki/Atomicity_(database_systems)

假设银行转帐，每个帐户提供商都有不同的数据库 - 钱必须离开一个帐户并更新到另一个帐户。如果它在中途失败 - 例如第二次数据库更新失败，钱离开了一个账户，但没有到另一个账户，这是不可接受的。

事务意味着其中一个更新失败意味着它们都被取消（回滚），以使数据保持事务开始之前的状态。

【讨论】：

【解决方案2】：

我个人认为它在 RDBMS 中并不明智——但我可以看到它降低了非常高负载数据库的设计复杂性。

例如，在电子商务案例中，您可能会将它们分区，以便产品库存在一个数据库中，而订单在另一个数据库中。在这种情况下，您不会在处理订单时减少库存计数并增加发票计数——在这种情况下，全局事务将是有意义的。

但 99% 有更好的替代方案可以在设计中解决。

-- 编辑：全局事务的陷阱--

这两点是我不建议使用全局事务的原因

第 1 点：

全局事务涉及多个数据库服务器（或者至少它们应该）——一个全局事务需要一个 DTC（分布式事务协调器）——使用这样的代理会降低你的查询速度，因为事情的原因是 ORDERS不是在单台机器的范围内完成的，而是涉及多台机器，也就是网络。

第2点：

如果您的查询设计不正确（大多数人不了解其中的细微之处），您最终可能会锁定单个数据库上的大部分表，有时人们甚至会使用单个查询锁定整个表。如果没有针对分布式查询进行适当的设计，您的应用程序将停滞不前，并且有人会被解雇：D。您需要确保您的查询最终只锁定它们必须锁定的内容，并且您必须尝试确保数据的这些锁定部分仅由一个查询同时使用。

为什么在分布式查询中锁定表会更糟？因为第 1 点。您现在锁定最后一个订单的订单时间更长。

-- 编辑：您可能想要调查的潜在领域--

集群技术和 HPC 经常使用Distributed Lock Managers。通过研究这些技术的数据管理变体，您将学到很多东西，因为它们会向您展示这些实现认为有必要在哪些地方获得全局锁（全局事务就是这样做的）。

【讨论】：

【解决方案3】：

当您想要影响多个数据库的事务操作时。

【讨论】：