首页 > 代码库 > JDBC、JTA、Spring的事务管理

JDBC、JTA、Spring的事务管理

Java事务的类型有三种:JDBC事务、JTA(Java Transaction API)事务、容器事务。    

   事务就是对一系列的数据库操作(比如插入多条数据)进行统一的提交或回滚操作,如果插入成功,那么一起成功,如果中间有一条出现异常,那么回滚之前的所有操作。
       这样可以防止出现脏数据,防止数据库数据出现问题。开发中为了避免这种情况一般都会进行事务管理。

JDBC中是通过Connection对象进行事务管理的
Hibernate中是通过Transaction进行事务管理,处理方法与JDBC中类似。
Spring中也有自己的事务管理机制,一般是使用TransactionMananger进行管理,可以通过Spring的注入来完成此功能。

 

JDBC的事务管理

     JDBC的一切行为包括事务是基于一个connection的,在JDBC中是通过Connection对象进行事务管理的,默认是自动提交事务,可以手工将自动提交关闭,通过commit方法进行提交,rollback方法进行回滚,如果不提交,则数据不会真正的插入到数据库中。
    

 基于J2EE分层架构设计思想,数据访问层应该专门处理数据访问,而业务逻辑则在业务逻辑层中处理。为了提高复用,数据访问层对象(DAO)的粒度通常都非常小,一个更新操作被封装在一个方法中,这样当有多个更新操作需要被捆绑为一个事务的时候,事务的处理只能在业务逻辑层中实现。
在不分层的情况下,一个典型的JDBC事务处理代码片断如下。
try {
conn =DriverManager.getConnection  
("jdbc:oracle:thin:@host:1521:SID","username","userpwd";
conn.setAutoCommit(false);//禁止自动提交,设置回滚点
stmt = conn.createStatement();
stmt.executeUpdate(“alter table …”); //数据库更新操作1
stmt.executeUpdate(“insert into table …”); //数据库更新操作2
conn.commit(); //事务提交
}catch(Exception ex) {  
         ex.printStackTrace();
         try {
              conn.rollback(); //操作不成功则回滚
         }catch(Exception e) {
e.printStackTrace();
         }
}

JDBC 事务是用 Connection 对象控制的。JDBC Connection 接口( java.sql.Connection )提供了两种事务模式:自动提交和手工提交。 java.sql.Connection 提供了以下控制事务的方法:

public void setAutoCommit(boolean)
public boolean getAutoCommit()
public void commit()
public void rollback()

使用 JDBC 事务界定时,您可以将多个 SQL 语句结合到一个事务中。JDBC 事务的一个缺点是事务的范围局限于一个数据库连接。一个 JDBC 事务不能跨越多个数据库。

JDBC的事务管理的安全性及效率分析

        如果直接使用基本的JDBC connection,肯定是关掉连接最安全。如果所有代码共用一个连接,会有效率问题,有时还会死锁、connection不是线程安全的。
       用不用DataSource跟关不关Connection没直接关系。 用DataSource只是把Connection的创建解离出来,可以变化。 DataSource是个接口,连接池是利用这个接口,返回一个Connection的代理(或者Wrapper,Delegate之类), 在调用这个代理的close方法时,不是直接关闭,而是把Connection放回连接池。 
       同时,因为需要事务需要保证使用一个连接, 而且如果每次调用 Dao都简单从DataSource建立连接, 不能保证连接一致,效率也会有些问题。 因此,比较好的做法是利用ThreadLocal,调用统一方法建立连接,该方法先检查ThreadLocal里有没有连接,有则利用, 没有则新建,连接放到ThreadLocal里。 
      Spring的DataSourceUtil是怎么写的,就是那个思路。ThreadLocal不是Connection的封装,而是Connection的保存点。 用连接池并不能保证你用的Connection是按线程一致的。 一般的连接池实现并不关心这点。 
      使用事务管理代码,在事务开始时,向连接池请求连接, 之后Dao不是直接向连接池请求连接而是获取ThreadLocal中的Connection, 在事务结束后,提交事务,关闭Connection(如果使用连接池,则将Connection返还给事务) 所以必须保证有事务提交和Connection关闭代码。 所以Spring的例子代码,一般是把事务管理放在Service层,而不是Dao层。

 

 

JTA的事务管理

     Java事务API(JTA;Java Transaction API)J2EE平台提供了分布式事务服务。一个分布式事务(distributed transaction)包括一个事务管理器(transaction manager)和一个或多个资源管理器(resource manager)。一个资源管理器(resource manager)是任意类型的持久化数据存储。事务管理器(transaction manager)承担着所有事务参与单元者的相互通讯的责任。下图显示了事务管理器和资源管理的间的关系。

    JTA 事务
 JTA (Java Transaction API) 为 J2EE 平台提供了分布式事务服务。
 要用 JTA 进行事务界定,应用程序要调用 javax.transaction.UserTransaction 接口中的方法。例如:
 import javax.transaction.*; 
 import javax.naming.*; 
   // ... 
   InitialContext ctx = new InitialContext(); 
   Object txObj = ctx.lookup(";java:comp/UserTransaction";); 
   UserTransaction utx = (UserTransaction) txObj; 

  应用程序有了UserTransaction对象的引用之后,就可以起动事务。 
       utx.begin();
       // ...
       DataSource ds = obtainXADataSource();
       Connection conn = ds.getConnection();
       pstmt = conn.prepareStatement("UPDATE MOVIES ...");
       pstmt.setString(1, "Spinal Tap");
       pstmt.executeUpdate();
       // ...
       utx.commit();

 让我们来关注下面的话:
     “用 JTA 界定事务,那么就需要有一个实现 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将可以参与 JTA 事务。一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnection s 是参与 JTA 事务的 JDBC 连接。”
 要使用JTA 事务,必须使用XADataSource来产生数据库连接,产生的连接为一个XA连接。
       XA连接(javax.sql.XAConnection)和非XA(java.sql.Connection)连接的区别在于:XA可以参与JTA 的事务,而且不支持自动提交。
       Note:
Oracle, Sybase, DB2, SQL Server等大型数据库才支持XA, 支持分布事务。 
My SQL 连本地都支持不好,更别说分布事务了。
JTA 方式的实现过程 :
       用XADataSource产生的XAConnection它扩展了一个getXAResource()方法,事务通过这个方法把它加入到事务容器中进行管理.对于调用者来说,根本看不到事务是如果管理的,你只要声明开始事务,告诉容器我下面的操作要求事务参与了,最后告诉事务说到这儿可以提交或回滚了, 别的都是黑箱操作。
       在使用JTA 之前,你必须首先实现一个Xid类用来标识事务(在普通情况下这将由事务管理程序来处理)。Xid包含三个元素:formatID、gtrid(全局事务标识符)和bqual(分支修饰词标识符)。
 下面的例子说明Xid的实现:

import javax.transaction.xa.*; 
public class MyXid implements Xid 

protected int formatId; 
protected byte gtrid[]; 
protected byte bqual[]; 
public MyXid() 


public MyXid(int formatId, byte gtrid[], byte bqual[]) 

this.formatId = formatId; 
this.gtrid = gtrid; 
this.bqual = bqual; 
}

 public int getFormatId() 

return formatId; 
}

 public byte[] getBranchQualifier() 

return bqual; 
}

 public byte[] getGlobalTransactionId() 

return gtrid; 
}

}
 其次,你需要创建一个你要使用的数据库的数据源:

public DataSource getDataSource() 
throws SQLException 

SQLServerDataSource xaDS = new 
com.merant.datadirect.jdbcx.sqlserver.SQLServerDataSource(); 
xaDS.setDataSourceName("SQLServer"); 
xaDS.setServerName("server"); 
xaDS.setPortNumber(1433); 
xaDS.setSelectMethod("cursor"); 
return xaDS; 
}

  例1?这个例子是用“两步提交协议”来提交一个事务分支:

XADataSource xaDS; 
XAConnection xaCon; 
XAResource xaRes; 
Xid xid; 
Connection con; 
Statement stmt; 
int ret; 
xaDS = getDataSource(); 
xaCon = xaDS.getXAConnection("jdbc_user", "jdbc_password"); 
xaRes = xaCon.getXAResource(); 
con = xaCon.getConnection(); 
stmt = con.createStatement(); 
xid = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); 
try { 
xaRes.start(xid, XAResource.TMNOFLAGS); 
stmt.executeUpdate("insert into test_table values (100)"); 
xaRes.end(xid, XAResource.TMSUCCESS); 
ret = xaRes.prepare(xid); 
if (ret == XAResource.XA_OK) { 
xaRes.commit(xid, false); 


catch (XAException e) { 
e.printStackTrace(); 

finally { 
stmt.close(); 
con.close(); 
xaCon.close(); 
}
 当然,实际过程中,我们不需要写这些代码,这些代码是JTA 最终的实现代码。
关于“两步提交协议”,可以参看下面的文章:
http://www.ibm.com/developerworks/cn/db2/library/techarticles/dm-0505weber/index.html

两阶段提交(Two-Phase-Commit) 协议

首先,两阶段提交(Two-Phase-Commit)事务的启动与常规的单阶段提交(One-Phase-Commit)事务类似。接着,应用程序/客户机对该两阶段提交(Two-Phase-Commit)操作中所涉及的所有数据库执行其修改工作。现在,在最终提交该事务之前,客户机通知参与的数据库准备 提交(第 1 阶段)。如果客户机从数据库收到一条“okay”,就发出命令向数据库提交该事务(第 2 阶段)。最后分布式事务(Distributed Transaction)结束。

本文中的例子演示了如何在 Java 中使用 JTA 实现两阶段提交(Two-Phase-Commit)协议。在该应用程序中,如果一个事务分支报告了错误,您就要负责进行错误处理。但是“两阶段提交协议 简介”小节中提到仍然存在一个问题,那就是如果第 2 阶段中一个事务分支发生故障,该怎么办呢?

如果再次查看程序代码,您可以看到在“第 1 阶段”和“第 2 阶段”之间有一个很小的时间间隔。在这一时间间隔中,出于某种理由,其中某一参与数据库可能崩溃。如果发生了,我们将陷入分布式事务已经部分提交的情形中。

假 定下列情形:在“第 1 阶段”之后,您从 DB2 和 IDS 数据库中都收到了“okay”。在下一步中,应用程序成功提交了 DB2 的事务分支。接着,应用程序通知 DB2 事务分支提交事务。现在,在应用程序可以通知 IDS 事务分支提交它这一部分之前,IDS 引擎由于断电发生崩溃。这就是一种部分提交全局事务的情形。您现在该怎么办呢?

在重启之后,DB2 和 IDS 都将尝试恢复打开的事务分支。该引擎等待来自应用程序的提示如何做。如果应用程序没有准备重新发送“第 2 阶段”的提交,该事务分支将被引擎所启动的试探性回滚中止。这是非常糟糕的,因为这将使该全局事务处于不一致状态。

一种解决方案是用一个小型应用程序连接引擎中打开的事务分支,并通知引擎提交或回滚这一打开的事务。如果您使用 IDS 作为后端,那么还有一个隐藏的 onmode 标志,允许您结束打开的事务分支。(onmode -Z xid )。

在 DB2 UDB 中,您可以发出 LIST INDOUBT TRANSACTIONS 来获得打开的 XA 事务的有关信息。您必须查看 DB2 Information Center 中的描述来解决该问题。

上面描述的情形是一个很好的例子,也是使用应用程序服务器(Application Server)或事务监控器(Transaction Monitor)的理由。在使用一个中间层服务器时,就由该服务器负责保持事情正常。

JDBC、JTA、Spring的事务管理