所有事务管理器（Atomikos，Bitronix，IBM WebSphere TM等）将“tranlogs”文件夹中的一些“事务日志”保存到文件系统。
当发生可怕的事情并且服务器停机时，有时会发生变更故障。 它们需要一些手动恢复程序。
我被告知，只需清除已损坏的tranlogs文件夹，我就有可能出现参与交易的资源状态不一致。
作为一个“愚蠢”的开发者，我对简单的概念感到更舒服。我想要认为分布式事务管理应该与常规事务管理相似：
问题
为什么我不能这样想？关于2PC有什么这么复杂的事情？
清除损坏的tranlogs时，确切的风险是什么？
如果我错了，我真的需要所有混乱的2PC文件系统状态。难道你不觉得TX经理能够以一种简单而丑陋的方式破坏存储状态吗？
答案 0 :(得分：7)
当我在1994年第一次面对现实生活中的2阶段提交时（最初是在更大的Oracle7环境中），我有类似的初步反应。通常不太可能使它变得简单，这真是一种血腥的耻辱。但回顾大学的算法书籍，很明显2PC没有通用的解决方案。
例如参见how to come to consensus in a distributed environment
当然，在许多特定情况下，事务的2PC提交可以更容易地完成或完全回滚并且影响较小。但是一般问题仍然存在，无法解决。
在这种情况下，交易经理必须在某个时间决定做什么;交易不能永远保持开放。因此，作为最终解决方案，他们将始终需要返回到他们自己的交易日志，因为一个或多个其他方可能无法在不久的将来可靠地传达状态。一些交易管理人员可能更高级，并且知道如何更轻松地解决某些案例，但仍需要最终的后备支持。
我很抱歉。修正它通常似乎与＆＃34; Falsity意味着什么＆＃34;在二进制逻辑中。
在Why can't I think like this?和What's so complicated about 2PC上：见上文。这个算法问题无法普遍解决。
On What are the exact risks when I clear broken tranlogs?：事务管理器有一些数据库支持它。删除translogs是一般关系数据库软件中的相同问题;你发现正在进行的交易的信息。某些数据库平台仍然可以包含某些或大部分整数文件。对于背景和一些数据库理论，see Wikipedia。
On Don't you feel sick about the fact that TX manager can actually break storage state in an easy and ugly manner?：是的，有时当我必须完成团队的大量工作时，我真的很讨厌它。但是，它让我有一份工作： - ）
从您的添加中我了解到您在考虑是否在项目中包含2PC。
在我看来，您的里程可能会有所不同。我们公司有2PC的政策：尽可能避免它。但是，在某些环境中，尤其是遗留系统和复杂环境（例如银行业中发现的环境），您无法解决这些问题。客户需要它，他们可能不愿意让您对其他基础设施组件进行重大更改。
当你必须做2PC时：做得好。我喜欢一个干净的软件和基础设施架构，而且非常简单，即使在5年后，它也很清楚它是如何工作的。
对于所有其他情况，我们远离两阶段提交。我们有自己的框架（Invantive Producer），从客户端到应用服务器到数据库后端。在这个框架中，我们选择在正常工作在分布式环境中时牺牲ACID的元素。应用程序开发人员必须注意自己的原子性。通常这很简单，甚至不需要考虑。例如，所有软件必须安全重启。即使是事务的原子性，这也需要一些思考才能在庞大的多用户环境中做到这一点（例如锁定问题）。
一般来说，这种愚蠢的方法很容易理解和维护。如果我们需要进行两阶段提交，我们就可以只替换框架上的一些插件并对客户端代码进行一些更改。
所以我的建议是：
我希望这会对你有所帮助。如果你能告诉我更多关于你的典型环境（#tables的大小，GB持久数据的大小，#concurrent用户的大小，典型的事务管理软件和平台），我可以做一些补充或改进。
关于是否建议DB与JMS结合：否，将DB与JMS结合起来通常没什么用处;它本身已经有一些数据库，因此有关事务日志的原始问题。
关于您的业务案例：我了解每个事件都会从模板发送电子邮件，并且外发邮件会在数据库中注册为事件。
这是一个难以破解的难题;我一直很喜欢进行安全审核，最简单的安全问题之一就是检查电子邮件的使用情况。
电子邮件 - 除了在明信片等大多数情况下不保密和防篡改外 - 无法保证在没有额外措施的情况下交付和/或阅读。例如，即使在您的邮件传输代理和收件人之间直接发送电子邮件，也可能会在没有通知事务监视器的情况下丢失数据。当涉及多个跃点时，甚至会变得更糟。例如，每个MTA都有自己的排队机制，可以在其上删除＆＃34;炸弹＆＃34;导致数据丢失。但是你也可以想到垃圾邮件措施，错误的配置，邮件循环，意外删除文件等等。即使你可以使用2PC注册发送电子邮件而不丢失任何交易信息，这也绝对不知道是否电子邮件将全部到达，甚至可以跨越第一跳。
我工作的公司为项目驱动的业务销售大型软件包。该软件包具有集成的排队机制，该机制还处理电子邮件事件。现在通常与Exchange的大多数实现相结合。几个月我们遇到了一个很好的问题：交易开始，打开邮件渠道，邮件作为MTA传递到Exchange，注册邮件已处理...事务中止，因为Oracle表空间已满。在下一次运行中，邮件再次传递到Exchange，再次中止，等等。此算法现在已得到增强，但从这个简单示例中您可以看到您需要所有端点在您的2PC中进行协作，即使某些端点也是如此在收到并显示您的电子邮件的组织中很远。
如果您需要采取措施确保发送或阅读电子邮件，则需要通过其他措施对其进行补充。请从文献中选择一个应用程序控件，用户控件和过程控件。