什么时候每个多个数据库连接有一个事务才有意义？
谁能帮我看看在什么样的场景下拥有一个共享数据库事务和多个连接才有意义？ 谢谢。
Can anyone help me see in what kind of scenarios it would make sense to have one shared database transaction and multiple connections?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您的意思是在一个事务中更新多个数据库，那么您将为 Atomicity 执行此操作 - http: //en.wikipedia.org/wiki/Atomicity_(database_systems)
假设考虑银行转账，每个帐户提供商都有不同的数据库 - 资金必须离开一个帐户并更新到另一个帐户。如果中途失败 - 例如第二次数据库更新失败，则资金已离开一个帐户但未到达另一个帐户，这是不可接受的。
该事务意味着其中一项更新失败意味着它们全部被取消（回滚），以使数据保持事务开始之前的状态。
If you mean multiple databases all being updated within one transaction then you would do this for Atomicity - http://en.wikipedia.org/wiki/Atomicity_(database_systems)
Hypothetically consider a bank transfer, with a different database for each account provider - the money has to leave one account and be updated to the other. If it fails part way through - e.g. the 2nd database update fails, then the money has left one account but not arrived in the other, which is not acceptable.
The transaction means that a failure on one of the updates means that they are all cancelled (rolled back), to leave the data in the state that it was before the transaction began.
就我个人而言，我认为它在 RDBMS 中并不明智——但是我可以看到它降低了非常高负载数据库的设计复杂性。
例如，在电子商务情况下，您可能会对它们进行分区，以便产品库存位于一个数据库中，而订单位于另一个数据库中。在这种情况下，您不希望在处理订单时减少库存计数并增加发票计数——在这种情况下，全局事务才有意义。
但99%有更好的替代方案可以在设计中解决。
-- 编辑：全局事务的陷阱 --
这 2 点是我建议不要使用全局事务的原因
第 1 点：
全局事务涉及多个数据库服务器（或者至少它们应该）-- 一个全局事务事务需要一个 DTC（分布式事务协调器）——使用这样的代理会按顺序降低查询速度，因为事情不是在单台机器的范围内完成的，而是涉及多台机器，这意味着网络。
第 2 点：
如果您的查询设计不正确（大多数人不理解其中的微妙之处），您可能最终会锁定各个数据库上的大部分表，有时人们甚至最终会使用单个查询锁定整个表。如果没有为分布式查询正确设计，您的应用程序将陷入停滞，并且有人会被解雇：D。您需要确保您的查询最终仅锁定它们必须锁定的内容，并且您必须尝试确保数据的这些锁定部分仅由一个查询同时使用。
为什么在分布式查询中锁定表会更糟糕？因为第 1 点。您现在可以根据更长的因素锁定最后订单。
-- 编辑：您可能想要研究的潜在领域 --
集群技术和 HPC 经常使用 分布式锁管理器。通过研究这些技术的数据管理变体，您将学到很多东西，因为它们将向您展示这些实现认为有必要获得全局锁的地方（这就是全局事务所做的）。
Personally I don't find it sensible in RDBMS -- however I can see it reducing design complexity for VERY high load databases.
For example in the e-commerce case you might have them partitioned so that product inventories are on one database and orders on another. In this case you would wan't to decrement a stock-count and increment a inivoice count when processing an order -- in that case a global transaction would make sense.
but 99% there is a better alternative that can be solved in the design.
-- edit : the pitfalls of global transactions --
These 2 points is why I would recommend not using global transactions
Point 1:
Global transactions involve multiple database servers (or at least they should) -- a global transaction requires a DTC (distributed transaction co-ordinator) -- employing such an agent will reduce the speed of your queries by ORDERS of factors since things aren't done in the scope of a single machine, but by involving multiple machines, which means the network.
Point 2:
If your queries aren't designed properly (most people do not understand the subtleties) you might end up locking large portions of the tables on the individual databases, sometimes people even end up locking entire tables with a single query. If things aren't properly designed for distributed queries your applications will come to a stand-still and someone will get fired :D. You need to make sure that your queries only end up locking only what they must and you must try to make sure these locked portions of the data are only concurrently used by one query.
Why is it worse to lock tables in a distributed query ? because of point 1. You locks now last orders upon orders of factors longer.
-- edit : potential area you might want to investigate --
Clustering technologies and HPC often make use of Distributed Lock Managers. You will learn a lot by studying the data management variants of these technologies, as they will show you where these implementations consider it is necessary to gain global locks (which is what a global transaction does).
当您想要影响多个数据库的事务操作时。
When you want a transactional operation that affects multiple databases.