dev2dev 首页 > 资源中心 > 专家Blog > 专家Blog文章
数据库不支持XA事务怎么办？
数据库不支持XA事务怎么办？
Deepak Vohra写了一篇文章，介绍了如何在WebLogic Server上配置和使用PostgreSQL。这篇文章无疑是使用PosgreSql的很好的入门，但是它没有说明该数据库面对企业级开发时的局限性。不要误解我的意思，我个人认为PosgreSql是一个很不错的数据库，对于特定的项目来说，即使比起领先的商业数据库RDBMS，它也是极好的免费替代方案。我自己就曾在几个项目中使用PostgreSql，它确实是一流的数据库，我推荐您在为下一个项目选择数据库时可以考虑一下它。它具有很多优点：易于安装和管理，可靠性好，设置了很不错的功能，具有标准兼容性，甚至还有顺序支持（这使它在PK生成策略方面可以很方便地与Oracle兼容），等等。
但我还是认为开发人员应该了解他们所使用的工具的局限性，甚至应该比了解工具的优点了解得更详细一些。作为一个优秀的数据库，PosgreSql缺乏对分布式(XA)事务的支持，至少在最新的版本8中还不支持。我不是很关注PosgreSql的开发，所以我不知道XA支持是否被列入以后版本的计划中了（如果有人知道详情，请在此回复，我将非常高兴能看到这种帖子）。实际上，我认为目前还没有任何免费的开源数据库具备XA支持，是这样的吧？希望能有人告诉我我错了。
关键是要分析项目的需求，看看对于这个项目来说XA支持是否重要。就我而言，我发现对于我所参与的大多数企业项目来说，XA支持非常重要。几乎每次应用程序必须同时处理多个资源管理器（考虑一下MDB更新数据库的情况）时，使用XA事务都可以获得更好的服务质量(QoS)。有人可能会说，大多数应用程序不需要XA（或者没有XA也行），这在某种程度上是正确的，但是往往会增加开发的工作量（在上面所提到的例子中是对副本的监测），或者会降低QoS。有时必须使用XA来交付用例所要求的功能。
不管怎么说，回到本文的主题上来——如果使用的数据库不支持XA事务，但是由于某些原因又需要使用它，那该怎么办？除了手动模拟或避免XA事务，还有一种事务最优化技术：Last resource commit（最近资源提交），在当前的大多数事务管理器实现中都包含这一技术。它的思想是，可以在具有若干个支持两阶段提交的资源的事务中使用不支持XA的单阶段资源（例如，只能提交或回滚，不支持准备阶段）。事务管理器随后威胁非XA资源（方式随管理器不同而有所不同），此时它先执行两阶段(XA)资源的准备阶段，然后如果它决定提交资源，就把控制权交给非XA资源。如果该资源提交了，那么管理器记录提交的决定，并尝试提交其他的资源（提交协议的第二阶段）。如果由于某种原因对非XA资源的提交失败，事务管理器将回滚到先前准备的XA资源。可以想象得出，会有一些失败场景，其中可能失去原子性，但是总体上来说这种场景在实践中出现得非常少。
WebLogic Server从版本9开始支持Last Resource Commit最优化（BEA称之为Logging Last Resource Transaction Option或LLR）。除了可以在XA事务中使用非XA资源外，这还是一种性能优化技术，因为XA驱动程序一般来说没有非XA驱动程序效率高，而且由于网络通信量和磁盘IO，XA协议本身也给系统增加了开销。
WebLogic 9中的LLR特性不应该与“Emulate Two-Phase Commit（模拟两阶段提交）”相混淆，后者是以前版本的JDBC连接池层的选项。两者之间有着微妙而重要的区别。根据BEA WebLogic 8的说明文档：
当选中Emulate Two-Phase Commit for non-XA Driver选项（EnableTwoPhaseCommit设为true）时，非XA的JDBC资源通常在调用XAResource.prepare() 方法时返回XA_OK。该资源试图提交或回滚它的本地事务以响应随后的XAResource.commit() 或XAResource.rollback() 调用。如果该资源提交或回滚失败，就会产生一个启发式错误。其结果是应用程序的数据可能会不一致。
可以看出，Emulate Two-Phase Commit的行为与LLR完全不同，而且使用时可能产生更多的启发式错误。
有许多不同的处理分布式事务的方法，而能够选择总是不错的。知道自己的数据库和事务管理器特性是值得的。如果您想了解一下包括JTA的事务处理理论和实践，我推荐一本很不错的书，Mark Little与人合著的“Java Transaction Processing : Design and Implementation”。
评论
我想LLR的要点在WebLogic 9.0 beta版JDBC的说明文档中有，并且按计划不久就会更新更详细的说明文档（可能与将要发布的WebLogic 9.0完全版本同时进行）。
最关键的一点是LLR具有完全的ACID（原子性、一致性、隔离性和永久性），而不像BEA和其他应用服务器供应商已经使用了很久的标准的last-participant-optimization（最近参与者优化）（又称为last-agent-optimization（最近代理优化））。
对于JDBC LLR，特定的JTA事务中应用程序的所有SQL工作都透明地指向同一个物理JDBC连接，而这个JDBC连接又维持着一个JDBC本地事务。在事务的持续时间内，事务中标准的JDBC getConnection()应用程序调用隐式地保留了该连接（及其本地事务），将其置于事务管理器(TM)的控制之下。随后同一个事务的getConnection() 应用程序调用隐式地创建了一个虚拟的连接，它又指回已保留的连接。如果JTA事务变成两阶段的（如果有非LLR资源参与，JTA LLR事务就会变成两阶段的），TM将使用该连接和本地事务存储一个2PC事务记录到数据库中，同时JTA基于事务处理日志“提交”而不是存储记录到一个文件中，大多数情况下都是这样。下面是LLR提交2PC事务时的算法：
- 1 TM基于所有参与的非LLR资源（如JMS服务器）调用prepare，如果有任一个资源返回“no”的话，就回滚所有的LLR和非LLR资源。
- 2 TM使用事务中已保留的JDBC连接和本地事务向数据库中的“LLR表”写入一个2PC记录。每个WebLogic服务器只创建一个“LLR表”。（如果这一步失败，TM将回滚所有的工作）
- 3 TM使用JDBC本地提交提交JDBC连接，并释放（关闭）JDBC连接，这样在一个本地事务中既提交了2PC记录注入，又提交了应用程序的SQL工作。（如果这一步失败，TM将测试数据库，看它是否存有2PC记录。如果找不到2PC记录，那么数据库工作肯定经过回滚，TM就回滚非LLR资源；否则，数据库工作肯定已经提交了，所以TM继续提交其余的资源）
- 4 如果3顺利完成，TM就提交非LLR资源。
- 5 在4完成后，TM最终删除2PC记录。
如果应用服务器在事务的某一个时间点崩溃，2PC记录的有无将决定事务的结果，并被用来促成事务的完成。在崩溃恢复时，若没有2PC记录，那么事务就必须回滚所有参与的资源；而如果有2PC记录，事务就必须提交所有参与的资源。
发表人：barnes，2005年7月18日，11:28 PM
感谢您的评论。是否有更详细地描述这种行为的BEA说明文档？
您描述得不是很清楚，至少对于我来说是这样的。到底“TLOG记录”保存在数据库中的什么地方？是否有专门针对它的表格，或者说它是如何保存的？我认为数据库是不知道事务协调程序的，而且也没有参与XA事务。您能更详细地说明一下吗？谢谢。
发表人：maximdim，2005年6月24日，10:16 AM
“WebLogic Server将从版本9开始支持Last Resource Commit优化（BEA称之为Logging Last Resource Transaction Option或LLR）”。
以前版本的Weblogic对last resource commit优化的支持体现在resource adapter应用程序（也称为Connector）的选项中。
WebLogic所独有的新增的9.0 JDBC Logging Last Resource (LLR)特性与标准的last resource commit (LRC)完全不同，而且要比后者安全得多。
理论上，LLR与完全的XA一样安全。这是因为，LLR两阶段事务与LRC不同，事务管理器的两阶段提交记录（TLOG记录）与应用程序的JDBC工作存储在数据库中的同一个本地事务。这消除了标准的LRC中的启发式故障，该故障会在提交最近资源之后、写TLOG提交记录之前、服务器崩溃时发生——这会导致所使用的其他资源的回滚。
Tom Barnes，BEA
发表人：barnes，2005年6月24日，09:03 AM
发表人：maximdim，2005年5月27日，10:35 AM
原文出处：http://dev2dev.bea.com/blog/maximdim/archive/2005/05/postgesql_in_en.html
作者其它文章
|
