数据库不支持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:关闭数据库连接失败!
");}
}