什么是xa 1次事务2次事务回滚

数据库不支持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”。

  

评论
Dimitri，
我想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

Tom，
感谢您的评论。是否有更详细地描述这种行为的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工作存储在数据库中的同一个本地事务。这消除

MS DTC 是Microsoft 为Microsoft Windows 系统提供的分布式事务处理工具。MS DTC 使用Microsoft 推出的久经考验的事务处理技术来支持XA 功能，例如完整的两步分布式

 

JDBC事务和JTA （XA）事务
事务简介
　　一般情况下，J2EE应用服务器支持JDBC事务、JTA（Java Transaction API）事务（一般由容器来进行管理）。通常，最好不要在程序中同时使用上述三种事务类型，比如在JTA事务中嵌套JDBC事务。第二方面，事务要在尽可 能短的时间内完成，不要在不同方法中实现事务的使用（事务的嵌套要求更加良好的设计）。

JDBC事务
　　在JDBC中怎样将多个SQL语句组合成一个事务呢？在JDBC中，打开一个连接对象Connection时，缺省是auto-commit模式，每 个SQL语句都被当作一个事务，即每次执行一个语句，都会自动的得到事务确认。为了能将多个SQL语句组合成一个事务，要将auto-commit模式屏 蔽掉。在auto-commit模式屏蔽掉之后，如果不调用commit()方法，SQL语句不会得到事务确认。在最近一次commit()方法调用之后 的所有SQL会在方法commit()调用时得到确认。例如下面的代码：
/**
* 测试Jboss中的JDBC事务
*

@author javer QQ:84831612


* @date 2005
*/
jjava.sql.Connection conn = null;
try{
javax.sql.DataSource ds = (javax.sql.DataSource) context.lookup("java:/OracleDS");
conn = ds.getConnection();
conn.setAutoCommit(false);
java.sql.Statement statement = conn.createStatement();
/**
*
* 数据库操作
*
*/
conn.commit();
} catch (Exception e) {
if(conn!=null)
try{conn.rollback();}catch(Exception e1){out.println("catch:事务回滚失败！
");}
out.println("catch:" + e.getClass() + ";" + e.getMessage()+"
");
}finally{
if(conn!=null)
try{conn.close();}catch(Exception e1){out.println("finally:关闭数据库连接失败！
");}
}
　　毕竟JDBC事务大多数程序员可能经常使用，而且比较相对简单，就不作过多的描述了


JTA （XA）事务
　　Java 事务 API(JTA) 及其同门兄弟 Java 事务服务(Java Transaction Service JTS)为 J2EE 平台提供了分布式事务服务。一个分布式的事务涉及一个事务管理器和一个或者多个资源管理器。一个资源管理器是任何类型的持久性的数据存储。事务管理器负责 协调所有事务参与者之间的通信。
　　与本地事务相比，XA 协议的系统开销相当大，因而应当慎重考虑是否确实需要分布式事务。只有支持 XA 协议的资源才能参与分布式事务。如果事务须登记一个以上的资源，则需要实现和配置所涉及的资源（适配器、JMS 或 JDBC 连接池）以支持 XA。

JTA事务工作流程
　　WEB服务器（比如：WebLogic Server）将根据以下条件返回不同种类的包装器：

　　　　1、所使用的 JDBC 驱动程序类是否支持 XA
　　　　2、是从 DataSource 还是从 TxDataSource 获得连接
　　　　3、调用 getConnection() 时是否在事务内运行
　　　　4、是否通过 RMI 从远程获得连接

　　决定返回哪种包装器的算法的工作方式如下：



JTA实例代码
/**
* 测试Jboss中的JTA事务
*

@author javer QQ:84831612


* @date 2005
*/
javax.transaction.UserTransaction tx = null;
java.sql.Connection conn = null;
try{
tx = (javax.transaction.UserTransaction) context.lookup("java:comp/UserTransaction");  //取得JTA事务，本例中是由Jboss容器管理
javax.sql.DataSource ds = (javax.sql.DataSource) context.lookup("java:/XAOracleDS");  //取得数据库连接池，必须有支持XA的数据库、驱动程序
tx.begin();
conn = ds.getConnection();
//conn.setAutoCommit(false);
java.sql.Statement statement = conn.createStatement();
String sql = "insert into testtable (cell1,cell2,cell3,cell4) values('"+System.currentTimeMillis()+"','','','')";
int insert = statement.executeUpdate(sql);
//conn.commit();  //JTA事务中不要嵌套JDBC事务啦！！！重要，切记，否则会抛出异常！！！
out.println("插入了" + insert + "行记录！
");
if(true)throw new Exception("故意抛出的异常！");
int num = statement.executeUpdate("delete testtable");
out.println("删除了" + num + "行记录！
");
tx.commit();
} catch (Exception e) {
if(tx!=null)
try{tx.rollback();}catch(Exception e1){out.println("catch:事务回滚失败！
");}
out.println("catch:" + e.getClass() + ";" + e.getMessage()+"
");
}finally{
if(conn!=null)
try{conn.close();}catch(Exception e1){out.println("finally:关闭数据库连接失败！
");}
}