Java事务处理总结

时间 2019-11-11

原文原文链接

1、什么是Java事务

　　事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）的缩写。事务的原子性表示事务执行过程当中的任何失败都将致使事务所作的任何修改失效。一致性表示当事务执行失败时，全部被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程当中对数据的修改，在事务提交以前对其余事务不可见。持久性表示已提交的数据在事务执行失败时，数据的状态都应该正确。html

通俗的理解，事务是一组原子操做单元，从数据库角度说，就是一组SQL指令，要么所有执行成功，若由于某个缘由其中一条指令执行有错误，则撤销先前执行过的全部指令。更简答的说就是：要么所有执行成功，要么撤销不执行。java

既然事务的概念从数据库而来，那Java事务是什么？之间有什么联系？ mysql

实际上，一个Java应用系统，若是要操做数据库，则经过JDBC来实现的。增长、修改、删除都是经过相应方法间接来实现的，事务的控制也相应转移到Java程序代码中。所以，数据库操做的事务习惯上就称为Java事务。程序员

2、为何须要事务　　

　　事务是为解决数据安全操做提出的，事务控制实际上就是控制数据的安全访问。具一个简单例子：好比银行转账业务，帐户A要将本身帐户上的1000元转到B帐户下面，A帐户余额首先要减去1000元，而后B帐户要增长1000元。假如在中间网络出现了问题，A帐户减去1000元已经结束，B由于网络中断而操做失败，那么整个业务失败，必须作出控制，要求A帐户转账业务撤销。这才能保证业务的正确性，完成这个操走就须要事务，将A帐户资金减小和B帐户资金增长方到一个事务里面，要么所有执行成功，要么操做所有撤销，这样就保持了数据的安全性。web

3、Java事务的类型

　　Java事务的类型有三种：JDBC事务、JTA(JavaTransaction API)事务、容器事务。sql

一、JDBC事务数据库

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

　　public void setAutoCommit(boolean)缓存

　　public boolean getAutoCommit()安全

　　public void commit()

　　public void rollback()

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

二、JTA(Java Transaction API)事务

　　JTA是一种高层的，与实现无关的，与协议无关的API，应用程序和应用服务器可使用JTA来访问事务。

　　JTA(Java Transaction API)容许应用程序执行分布式事务处理:在两个或多个网络计算机资源上访问而且更新数据，这些数据能够分布在多个数据库上,JDBC驱动程序的JTA支持极大地加强了数据访问能力。

若是计划用 JTA 界定事务，那么就须要有一个实现javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将能够参与 JTA 事务。一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnection是参与 JTA 事务的 JDBC 链接。

您将须要用应用服务器的管理工具设置 XADataSource 。从应用服务器和 JDBC 驱动程序的文档中能够了解到相关的指导。

J2EE 应用程序用 JNDI 查询数据源。一旦应用程序找到了数据源对象，它就调用 javax.sql.DataSource.getConnection() 以得到到数据库的链接。

XA 链接与非 XA 链接不一样。必定要记住 XA 链接参与了 JTA 事务。这意味着 XA 链接不支持 JDBC 的自动提交功能。同时，应用程序必定不要对 XA 链接调用 java.sql.Connection.commit() 或者java.sql.Connection.rollback() 。相反，应用程序应该使用UserTransaction.begin()、 UserTransaction.commit() 和 serTransaction.rollback() 。
　　JTA(Java Transaction API)容许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问而且更新数据。JDBC驱动程序的JTA支持极大地加强了数据访问能力。
　　本文的目的是要提供一个关于的Java事务处理API（JTA）的高级的概述，以及与分布式事务相关的内容。一个事务处理定义了一个工做逻辑单元，要么完全成功要么不产生任何结果。一个分布式事务处理只是一个在两个或更多网络资源上访问和更新数据的事务处理，所以它在那些资源之间必然是等价的。在本文中，咱们主要关心的是如何处理关系数据库系统。

咱们要讨论的分布式事务处理（DTP）模型中包含的组件是：
　　　应用程序
　　　应用程序服务器
　　　事务管理程序
　　　资源适配器
　　　资源管理程序
　　在之后的内容中，咱们将描述这些组件以及它们与JTA和数据库访问的关系。
　　最好把分布式事务处理中包含的组件看做是独立的过程，而不是考虑它们在一个特定的电脑中的位置。这些组件中的一些能够保存在单机中，或者也可在好几台机器之间分布。
　　最简单的例子：用于本地数据库事务处理的应用程序

　　关系数据库访问的最简单的形式仅仅包括应用程序、资源管理程序和资源适配器。应用程序只不过是发送请求到数据库而且从数据库中获取数据的最终用户访问点

　　咱们讨论的资源管理程序是一个关系数据库管理系统（RDBMS），好比Oracle或者SQL Server。全部的实际数据库管理都是由这个组件处理的。

　　资源适配器是外部空间之间的通讯管道组件，或者是请求翻译器，在单个的本地事务处理中，这是一个JDBC驱动程序。应用程序发送一个用于JDBC驱动程序数据的请求，而后翻译这个请求并把它经过网络发送到数据库中。数据库把数据发送回驱动程序，而后把翻译的结果发送回应用程序。

　　到目前为止，咱们说明了单个的本地事务处理，而且描述了分布式事务处理模型的五个组件中的四个。第五个组件，事务管理程序只有当事务将要被分配的时候才会开始被考虑。
　　分布式事务处理和事务管理程序

　　像咱们前面所提到的，一个分布式事务处理是一个在两个或更多网络资源上访问和更新数据的事务处理。

　　这些资源能够由好几个位于一个单独服务器上的不一样的关系型数据库管理系统组成，好比说Oracle、SQL Server和Sybase；它们也能够包含存在于若干不一样的服务器上的同一种数据库的若干个实例。在任何状况下，一个分布式事务处理包括各类的资源管理程序之间的协同做用。这个协同做用是事务管理程序。

　　事务管理程序负责做出要么提交(commit)要么退回(rollback)任何分布式事务处理的决定。一个提交决定应该致使一个成功的事务处理；而退回操做则是保持数据库中的数据不变。 JTA指定一个分布式事务处理中的事务管理程序和另外一个组件之间的标准Java接口：应用程序，应用程序服务器和资源管理程序。
　　JTA的三个接口部分：
　　一、UserTransaction，javax.transaction.UserTransaction接口提供可以编程地控制事务处理范围的应用程序。 javax.transaction.UserTransaction方法开启一个全局事务而且使用调用线程与事务处理关联。
　　二、Transaction Manager，javax.transaction.TransactionManager接口容许应用程序服务器来控制表明正在管理的应用程序的事务范围。
　　三、XAResource，javax.transaction.xa.XAResource接口是一个基于X/OpenCAE Specification的行业标准XA接口的Java映射。
　　注意，一个限制性环节是经过JDBC驱动程序的XAResource接口的支持。JDBC驱动程序必须支持两个正常的JDBC交互做用：应用程序和/或应用程序服务器，并且以及JTA的XAResource部分。

　　编写应用程序水平代码的开发者不会关心分布式事务处理管理的细节。这是分布式事务处理基本结构的工做：应用程序服务器、事务管理程序和JDBC驱动程序。应用程序代码中惟一的须要注意的就是当链接处于一个分布式事务范围内的时候，不该该调用一个会影响事务边界的方法。特别的是，一个应用程序不该该调用Connection方法commit、rollback和setAutoCommit(true)，由于它们将破坏分布式事务的基本结构管理。
　　分布式事务处理
　　事务管理程序是分布式事务基本结构的基本组件；然而JDBC驱动程序和应用程序服务器组件应该具有下面的特征：
　　驱动程序应该实现JDBC 2.0应用程序接口，包括OptionalPackage接口XADataSource和XAConnection以及JTA接口XAResource。
　　应用程序服务器应该提供一个DataSource类，用来实现与分布式事务基本结的交互以及一个链接池模块（用于改善性能）。
　　分布式事务处理的第一步就是应用程序要发送一个事务请求到事务管理程序。虽然最后的commit/rollback决定把事务做为一个简单的逻辑单元来对待，可是仍然可能会包括许多事务分支。一个事务分支与一个到包含在分布式事务中的每一个资源管理程序相关联。所以，到三个不一样的关系数据库管理的请求须要三个事务分支。每一个事务分支必须由本地资源管理程序提交或者返回。事务管理程序控制事务的边界，而且负责最后决定应该提交或者返回的所有事务。这个决定由两个步骤组成，称为Two - Phase Commit Protocol。
　　在第一步骤中，事务管理程序轮询全部包含在分布式事务中的资源管理程序（关系数据库管理）来看看哪一个能够准备提交。若是一个资源管理程序不能提交，它将不响应，而且把事务的特定部分返回，以便数据不被修改。
　　在第二步骤中，事务管理程序判断否认响应的资源管理程序中是否有可以返回整个事务的。若是没有否认响应的话，翻译管理程序提交整个事务而且返回结果到应用程序中。
　　开发事项管理程序代码的开发者必须与全部三个JTA接口有关：UserTransaction、TransactionManager和XAResource，这三个接口都被描述在
　　Sun JTA specification中。JDBC驱动程序开发者只须要关心XAResource接口。这个接口是容许一个资源管理程序参与事务的行业标准X/OpenXA协议的Java映射。链接XAResource接口的驱动程序组件负责在事务管理程序和资源管理程序之间担任"翻译"的任务。

三、容器事务

容器事务主要是J2EE应用服务器提供的，容器事务大可能是基于JTA完成，这是一个基于JNDI的，至关复杂的API实现。相对编码实现JTA事务管理，咱们能够经过EJB容器提供的容器事务管理机制（CMT）完成同一个功能，这项功能由J2EE应用服务器提供。这使得咱们能够简单的指定将哪一个方法加入事务，一旦指定，容器将负责事务管理任务。这是咱们土建的解决方式，由于经过这种方式咱们能够将事务代码排除在逻辑编码以外，同时将全部困难交给J2EE容器去解决。使用EJB CMT的另一个好处就是程序员无需关心JTA API的编码，不过，理论上咱们必须使用EJB。

4、三种事务差别

　　一、JDBC事务控制的局限性在一个数据库链接内，可是其使用简单。

　　二、JTA事务的功能强大，事务能够跨越多个数据库或多个DAO，使用也比较复杂。

　　三、容器事务，主要指的是J2EE应用服务器提供的事务管理，局限于EJB应用使用。

5、总结

　　事务控制是构建J2EE应用不可缺乏的一部分，合理选择应用何种事务对整个应用系统来讲相当重要。通常说来，在单个JDBC 链接链接的状况下能够选择JDBC事务，在跨多个链接或者数据库状况下，须要选择使用JTA事务，若是用到了EJB，则能够考虑使用EJB容器事务。

在weblogic在对几种JTA的应用场景进行的测试，总结以下：

测试代码片断：

public void doTest()throws Exception{
        UserTransaction tx = null;
        try{
               Context ctx = new InitialContext();
               tx =(UserTransaction)ctx.lookup("javax.transaction.UserTransaction");
               tx.begin();
               doResource1();
               doResource2();
               tx.commit();
           }catch(Exception e){
               e.printStackTrace();
               if(tx != null){
                   tx.rollback();
               }
            }
    }

    private voiddoResource1()throws Exception{
            ...
            DataSourceds = (DataSource)ctx.lookup("A|B|C|D|E");
            con =ds.getConnection();
            ...
    }

    private voiddoResource2()throws Exception{
            ...
            DataSourceds = (DataSource)ctx.lookup("A|B|C|D|E");
            con =ds.getConnection();
            ...
    }

共建立了五个链接池以及对应的数据源

A： OracleLocalDataSource
B： OracleLocalDataSource2
C： OracleXADataSource
D： OracleXADataSource2
E： MysqlLocalDataSource

A、B：【oracle.jdbc.driver.OracleDriver】
C、D：【oracle.jdbc.xa.client.OracleXADataSource】
E：【org.gjt.mm.mysql.Driver】

对于doResource1和doResource2所用不一样数据源类型搭配测试状况以下：

[A-A]:运行成功,且weblogic进行了优化，两次操做得到的con实际上是同一个链接对象
[A-B]:运行失败,不容许在一次事务中从不一样的数据库获取local事务类型的链接
[A-E]:运行失败,不容许在一次事务中从不一样的数据库获取local事务类型的链接
[A-D]:在容许Emulate Two-Phase Commit for non-XA Driver的状况下成功,不然失败
[C-C]:运行成功,可是不像(A-A)的状况,两次得到con的对象不是同一个对象,weblogic并为对该状况进行优化
[C-D]:运行成功，这是典型的2PC(two-phase transaction commitprocess)用于分布式多资源的应用状况

对于C、D的XA类型驱动程序，weblogic默认不容许经过con.setAutoCommit(false)的方式进行事务启动，能够经过容许（SupportsLocal Transaction）选项启动本地事务。

记得EJB的部署文件的事务属性<trans-attribute>RequiresNew</trans-attribute>的状况，在调用该EJB函数时若是已经存在一个事务进行中，那么要求容器挂起该事务，启动新的事务进行函数调用，直到函数结束后，再恢复原来的事务继续进行。

也许你会想到用如下的方式进行:

UserTransaction tx =(UserTransaction)ctx.lookup("javax.transaction.UserTransaction");
UserTransaction tx2 = (UserTransaction)ctx.lookup("javax.transaction.UserTransaction");

tx.begin();

tx2.begin();

tx2.commit();

tx.commit();

以上代码会抛出以下异常：
javax.transaction.NotSupportedException: Another transaction is associated withthis thread.

查找了sun的 JTA specification 说明以下：
The UserTransaction.begin method starts a global transaction and associates thetransaction with the calling thread. The transaction-to-thread association ismanaged transparently by the Transaction Manager. Support for nestedtranactions is not required. The UserTransaction.begin method throws theNotSupportedException when the calling thread is already associated with atransaction and the transaction manager implementation does not support nestedtransactions.

看来weblogic的Transaction没有实现嵌套功能，那么容器如何RequiresNew的ejb事务状况呢，就得借助于TransactionManager类了

tm =(TransactionManager)ctx.lookup("javax.transaction.TransactionManager");
tx = (UserTransaction)ctx.lookup("javax.transaction.UserTransaction");
tx.begin();
   ...
transaction = tm.suspend();
doNestedTransaction();
tm.resume(transaction);
   ...
tx.commit();

其实以上问题的顺利解决都归功于sun完整的官方资料，想一想从事Java快两年了个人大部分知识都是来源于“东拼西凑”：书籍、论坛、项目...看来是该花点时间好好读读sun网站的各类specification了。

今天对XA和非XA驱动进行了更进一步的研究，终于搞清了之前些模菱两可的问题。

经过测试得知，在JTA事务中(包括JDBC事务以及非事务环境下)，应用程序操做的connection其实都是weblogic的包装类

weblogic.jdbc.wrapper.JTSConnection_weblogic_jdbc_oracle_OracleConnection

weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_weblogic_jdbcx_base_BaseConnectionWrapper

weblogic.jdbc.wrapper.JTSConnection_com_mysql_jdbc_Connection

因为XA驱动实现了XAResource的接口，因此能参与彻底的2PC协议，保证多资源参与的事务的原子操做。可是非XA驱动没有实现XAResource的接口的接口，没法彻底参与2PC协议,因此在分布式事务（即JTA事务）中weblogic实现了非XA驱动的XAResource包装（wrapper），用来模拟（或者说欺骗TM^_^）两步提交，在...\bea\weblogic81\server\lib\weblogic.jar类包中，经过反编译weblogic.jdbc.wrapper.JTSConnection和weblogic.jdbc.wrapperJTSXAResourceImpl类获得以下代码片断：

JTSXAResourceImpl源码片断：
    public int prepare(Xid xid)throws XAException
    {
        if(!jtsConn.getEnable2PC())
            throw newXAException("JDBC driver does not support XA ... );
        else
            return 0;
    }

    public voidcommit(Xid xid, boolean flag)throws XAException
    {
        ...
        jtsConn.internalCommit();
        ...
    }
    public void rollback(Xid xid)throws XAException
    {
        ...
        jtsConn.internalRollback();
        ...
    }

JTSConnection源码片断：
    public synchronized void internalRollback() throwsSQLException
    {
        ...
        connection.rollback();
        ...
        internalClose();
        ...
    }

    public voidinternalCommit() throws SQLException
    {
        ...
        connection.commit();
        ...
        internalClose();
        ...
    }

可知若是非XA驱动容许两步提交时(enableTwoPhaseCommit),当TransactionManager调用prepare时XAResource包装类只是简单的返回XA_OK(0)，当TransactionManager调用commit或rollback时XAResource包装类将代理调用非XA驱动的JDBC connection的commit或rollback，因此若是在commit或rollback出现异常后，应用程序的数据将有可能处于不一致的状态（其实若是XA驱动在TM调用XAResource的commit或者rollback时出错，系统数据也会处于不一致的状态，不过出现这种状况的几率是微乎其微的，若是想搞三步、四步...提交的话，就会进入鸡生蛋、蛋生鸡的无休止讨论的问题了^_^）。

接下来让咱们研究一下链接关闭的问题，细心的人也许早已发现JTA与JDBC的事务对于应用层的操做有点“自相矛盾”，JDBC的先得到con在setAutoCommit(false)启动事务，而后关闭con，在commit或者rollback事务，然而JTA的顺序正好相反，先tx.begin()，再获取con，而后关闭con，最后再tx.commit或者rollback。（这里有句话您看完一下内容后会认同的：For both non-XAand XA driver, you can close the connection after the distributed transactionis completed.）

当应用程序调用Connection.close时容器经过注册的ConnectionEventListener事件通知TransactionManager，以便TransactionManager结束Connection对应的XAResource对象的事务分支（end函数调用），对于XA驱动的链接此时在Connection.close以后便可将该链接返回XA链接池供其余业务使用。

因此JTA spec中的提示到:

A distributed transaction maystill be active after a participating Connection object is closed. This is nottrue for local transactions。

可是对于非XA驱动调用Connection.close后的状况将有全部区别，因为XA驱动须要用connection进行最后的commit或rollback，因此应用程序调用Connection.close以后只是对与应用不能再使用包装的Connection，但容器并无真正将链接返回链接池，而是在调用XAResource包装类的commit和rollback时，进而调用JTSConnection的internalCommit和internalRollback，最终再JTSConnection的这两个函数中internalClose将非XA的链接释放到链接池中。

因此weblogic的资料（http://edocs.bea.com/wls/docs60/faq/transactions.html）中说:
the number of active distributed transactions using the non-XA
connection pool is limited by the maximum capacity of the JDBC connection pool

When you use an XA driver, theconnection management is more scalable. WLS does not hold on to the same physicalXA connection until the transaction is committed or rolled back. In fact, inmost cases, the XA connection as only held for the duration of a methodinvocation. WLS JDBC wrappers intercept all JDBC calls and enlist theXAResource associated with the XA connection on demand. When the methodinvocation returns to the caller, or when it makes another call to anotherserver, WLS delists the XAResource associated with the XA connection.

WLS also returns the XA connectionto the connection pool on delistment if there are no open result sets. Also,during commit processing, any XAResource object can be used to commit anynumber of distributed transactions in parallel. As a result, neither the numberof active distributed transactions using the XA connection pool nor the numberof concurrent commit/rollbacks is limited by the maximum capacity of theconnection pool. Only the number of concurrent database access connections islimited by the maximum capacity of the connection pool.

对于以上XA驱动的con在关闭后，没必要等待事务结束即释放回链接池的推论，我在weblogic上对oracle作了些好像没有效果，weblogic中有个 Keep XA Connection Till Transaction Complete 的选项我也没有选中啊。不知是我对JTA的理解有误，仍是说与我用的数据库驱动或者是weblogic的实现有关，有时间要好好研究一下了。

最后请注意：除非将XA驱动的链接池设置容许【Supports Local Transaction】选项，不然在非事务的环境下对con进行的操做将抛出以下错误，甚至是getAutoCommit()操做

刚看完《hibernate in action》，前段时间hiberante3又发布了3.0.2版，对于hibernate的这种更新路线我仍是比较喜欢的，2.x的版本继续更新发展这对于已经在项目中应用hibernate的人来讲是再庆幸不过的了（不过这也许是废话，若是GAVIN KING不继续发展2.x谁还敢用3.x，由于...4.x...），3版本是不兼容2的，总体包名都进行了完全的变更，若是想移植的话其实工做量也不大不少接口都是同样的，配置文件也尽可能保持之前的规范，并且3会有更多使人兴奋的新特性，这种走不一样版本分支、不拖泥带水的革新，至少让我感受比一味坚持要兼容老版本的EJB3来得爽！

下面我还来说讲hibernate中的JTA事务应用。

本人对于hibernate我仍是比较喜欢的，特别是在领域驱动设计开发，彻底消除了面向对象与面向关系（数据库）的抗阻，真的很爽，（不是很喜欢老的开发方法，一开始就分析系统有多少个实体，有多少数据表）

//////////////如下为hibernate中的经典事务操做步骤 //////////////

Session sess = factory.openSession();
Transaction tx = null;
try {
        tx = sess.beginTransaction();
        // do some work
        ...
        tx.commit();
}
catch (RuntimeException e) {
        if (tx != null) tx.rollback();
        throw e; // or display error message
}
finally {
        sess.close();
}

hibernate2中只有JDBCTransaction和JTATransaction两种事务类，对于使用JTA事务的应用，
应该说JTATransaction适用于绝大部分状况，可是CMT状况将存在一些例外：

////////// begin片断 //////////
        newTransaction = ut.getStatus() ==Status.STATUS_NO_TRANSACTION;
        if (newTransaction) {
               ut.begin();
               log.debug("Began a new JTA transaction");
        }
////////// commit片断 //////////
        if (session.getFlushMode()!=FlushMode.NEVER ) session.flush();
        if (newTransaction) {
               try {
                       log.debug("Committing UserTransaction started by Hibernate");
                       ut.commit();
               }
////////// rollback片断 //////////
        if (newTransaction) {
               if (!commitFailed) ut.rollback();
        }
        else {
               ut.setRollbackOnly();
        }

经过以上JTATransaction源码可知，若是调用session.beginTransaction()时已经处于事务状态，hibernate只是简单的加入这个事务，这对于Requires和RequiresNew等状况是没有问题的，可是若是调用session.beginTransaction()时不处于事务环境，那么JTATransaction将启动事务。这对于一个经过容器管理(CMT)事务的且不须要启事务的EJB调用将会存在矛盾。固然对于CMT的状况你能够不调用任何hibernate的Transaction事务函数，只经过session进行CRUD(create、read、update、delete)操做，避开这个例外的状况，可是这存在一个新问题：通常的hibernate操做代码并不直接手工调用session.flush，而是经过tx.commit时由hibernate内部自动进行flush，因此若是想用以上的小伎俩，那么请记得在操做最后手工添加session.flush函数。这样CMT中的代码片断能够改造以下：

Session sess =factory.openSession();
try {
        // do some work
        ...
        session.flush();
}
catch (RuntimeException e) {
        context.setRollbackOnly();
        throw e; // or display error message
}
finally {
        sess.close();
}

为了解决以上问题hibernate3进行了改进，增长了CMTTransaction类，以及两个新属性：
1:【hibernate.transaction.flush_before_completion】
If enabled, the session will be automatically flushed during the beforecompletion
phase of the transaction. (Very useful when using Hibernate with CMT.)

2:【hibernate.transaction.auto_close_session】
If enabled, the session will be automatically closed during the beforecompletion
phase of the transaction.(Very useful when using Hibernate with CMT.)

因此对于CMT的状况，只要将以上两个参数设置为true，hibernate自动会在事务提交时进行flush和close，具体实现细节能够看看org.hibernate.transaction.CacheSynchronization的实现和
JDBCContext中的registerSynchronizationIfPossible函数。因为CMT状况下容器对于RuntimeException的异常将进行事务回滚，因此能够经过在须要回滚事务时抛出RuntimeException类型的异常，那么甚至能够彻底不用操做hibernate的Transaction类的任何API。

对于JTA的配置问题注意如下几点：

tx = (UserTransaction)ctx.lookup("javax.transaction.UserTransaction");
tx = (UserTransaction) ctx.lookup("java:comp/UserTransaction");

对于weblogic因为以上两种方式都能找到JTA事务对象，而hibernate默认的查找名以下为【java:comp/UserTransaction】，因此在weblogic中设置启用JTA方式，只须要配置【hibernate.transaction.factory_class】属性为【org.hibernate.transaction.JTATransactionFactory】，【hibernate.transaction.manager_lookup_class】属性不配也行。

还有一种方式经过配置以下属性，能够指定UserTransaction的JNDI名
<property name="jta.UserTransaction">javax.transaction.UserTransaction</property>

另外还有一个JTA调用超时问题，对于weblogic默认是30秒，能够经过控制台进行动态配置，若是事务处理操做配置的超时时间对于weblogic的状况，容器将会自动调用internalRollback()。

最后一点须要注意的是数据库事务隔离级别的设置：

----------------------------------------------------------------
■ Readuncommitted:
这个级别是不安全的，事务中的查询会读到当前其它事务正在设置当时还未提交的数据

■ Readcommitted:
这个级别相对比较安全，事务中读到的数据都是已经获得提交的数据，可是若是两次读取同一个条记录，可是在两次读取的过程当中有另外的事务更改了改记录并成功提交的话，则会出现同一事务中两次读取同一条记录数据不一致的状况。这种状况不多出现，由于通常同一事务的程序不会重复读取同一条记录，若是用hibernate就更安全了，hibernate的一级缓存不会让程序向数据库两次读取同一条记录。

■ Repeatable read:
这个级别解决了同一事务两次读取数据结果不一样的状况，这个级别也是不少数据库的默认事务级别（如mysql）

■Serializable:
这个级别会使全部事务串行化工做，每一个事务只能排队进行数据库操做，相似单线程的Servlet的工做机制，这样在并不是量较高的数据库访问时，数据库操做效率将极其底下，应该避免使用
----------------------------------------------------------------
hibernate中经过【hibernate.connection.isolation】属性进行设置，可是若是hibernate的数据库链接是经过数据源得到的话，hibernate则再也不对事务隔离级别进行设置，因此对于数据源的到的数据库链接只能经过设置应用服务器配置数据库隔离级别，固然也能够经过Connection con=session.connection();con.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);进行手工设置。