spring与hibernate的整合问题—事务管理

一、什么是Java事务 
通常的观念认为，事务仅与数据库相关。 
事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性（atomicity）、一致性（consistency）、隔离性 （isolation）和持久性（durability）的缩写。事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示 当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见。持 久性表示已提交的数据在事务执行失败时，数据的状态都应该正确。 
通俗的理解，事务是一组原子操作单元，从数据库角度说，就是一组SQL指令，要么全部执行成功，若因为某个原因其中一条指令执行有错误，则撤销先前执行过的所有指令。更简答的说就是：要么全部执行成功，要么撤销不执行。 
既然事务的概念从数据库而来，那Java事务是什么？之间有什么联系？ 
实际上，一个Java应用系统，如果要操作数据库，则通过JDBC来实现的。增加、修改、删除都是通过相应方法间接来实现的，事务的控制也相应转移到Java程序代码中。因此，数据库操作的事务习惯上就称为Java事务。 
二、为什么需要事务 
事务是为解决数据安全操作提出的，事务控制实际上就是控制数据的安全访问。具一个简单例子：比如银行转帐业务，账户A要将自己账户上的1000元 转到B账户下面，A账户余额首先要减去1000元，然后B账户要增加1000元。假如在中间网络出现了问题，A账户减去1000元已经结束，B因为网络中 断而操作失败，那么整个业务失败，必须做出控制，要求A账户转帐业务撤销。这才能保证业务的正确性，完成这个操走就需要事务，将A账户资金减少和B账户资 金增加方到一个事务里面，要么全部执行成功，要么操作全部撤销，这样就保持了数据的安全性。 
三、Java事务的类型 
Java事务的类型有三种：JDBC事务、JTA(Java Transaction API)事务、容器事务。 
1、JDBC事务 
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 事务不能跨越多个数据库。 
2、JTA(Java Transaction API)事务 
JTA是一种高层的，与实现无关的，与协议无关的API，应用程序和应用服务器可以使用JTA来访问事务。
JTA允许应用程序执行分布式事务处理–在两个或多个网络计算机资源上访问并且更新数据，这些数据可以分布在多个数据库上。JDBC驱动程序的JTA支持极大地增强了数据访问能力。 
如果计划用 JTA 界定事务，那么就需要有一个实现 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 接口的 JDBC 驱动程序。一个实现了这些接口的驱动程序将可以参与 JTA 事务。一个 XADataSource 对象就是一个 XAConnection 对象的工厂。 XAConnection s 是参与 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() 。 
3、容器事务 
容器事务主要是J2EE应用服务器提供的，容器事务大多是基于JTA完成，这是一个基于JNDI的，相当复杂的API实现。相对编码实现JTA事 务管理，我们可以通过EJB容器提供的容器事务管理机制（CMT）完成同一个功能，这项功能由J2EE应用服务器提供。这使得我们可以简单的指定将哪个方 法加入事务，一旦指定，容器将负责事务管理任务。这是我们土建的解决方式，因为通过这种方式我们可以将事务代码排除在逻辑编码之外，同时将所有困难交给 J2EE容器去解决。使用EJB CMT的另外一个好处就是程序员无需关心JTA API的编码，不过，理论上我们必须使用EJB。 
四、三种事务差异 
1、JDBC事务控制的局限性在一个数据库连接内，但是其使用简单。 
2、JTA事务的功能强大，事务可以跨越多个数据库或多个DAO，使用也比较复杂。 
3、容器事务，主要指的是J2EE应用服务器提供的事务管理，局限于EJB应用使用。 
五、总结 

事务控制是构建J2EE应用不可缺少的一部分，合理选择应用何种事务对整个应用系统来说至关重要。一般说来，在单个JDBC 连接连接的情况下可以选择JDBC事务，在跨多个连接或者数据库情况下，需要选择使用JTA事务，如果用到了EJB，则可以考虑使用EJB容器事务。

spring中事务管理

一、简单介绍

spring中的事务管理主要是用来管理对数据库进行操作的事务，一般是应用于service层。分为几种：

1.编程式事务管理（如jdbc中设置取消数据库的自动提交功能）

conn=dataSource.getConnection();

conn.setAutoCommit(false);//此处表示取消数据库的自动提交功能，不要每条sql提交一次

... ...//此处是多条sql语句的处理

conn.commit()//在此处统一提交

2.声明式事务管理

多数声明式事务管理要比编程式来的方便，它能够将事务管理代码从业务逻辑中分离出来。例如通过AOP对关注点进行横切管理。可以通过AOP对事务进行管理，在配置文档中进行。

3.更加常用的一种方式是spring中通过注解方式实现

[html]  view plain copy

1. <tx:annotation-driven transaction-manager="transactionManager" />  
2.     <bean id="transactionManager"  
3.         class="org.springframework.orm.hibernate3.HibernateTransactionManager">  
4.         <property name="sessionFactory" ref="sessionFactory" />  
5.     </bean>  

注：事实上当事务管理器名字为transactionManager时，就不需要加transaction-manager属性，此处的事务管理器是 HibernateTransactionManager，针对对象/关系映射框架存取数据库。当然其他的数据管理器还有DataSourceTransaction（针对只有一个数据源）等。

在spring文档中注入了事务管理器之后，代码中应该怎么办呢？

@Transactional(propagation =Propagation.REQUIRED)

public List getAssignmentList(Model model) {

getHibernateTemplate().update(model);

}//注：默认的事务传递方式就是 REQUIRED 方式，因此上面的注解括号里头的可以不用写。

详细如图：

二、下面介绍事务的传递方式

PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。 PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。 PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。 PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。

三、 隔离方式（针对并发问题）

在并发环境中，一个数据库系统会同时为各种各样的客户程序提供服务。对于同时运行的多个事务，当这些事务访问数据库中的相同的数据时候，如果没有采取必要的隔离机制，就会导致各种并发问题，这些并发问题可以归纳为以下几类：

1、第一类丢失更新：撤销一个事务时，把其他事务已经提交的数据覆盖。

2、脏读：一个事务读到另一个事务未提交的更新数据。（即另一个事务最后rollback了）

3、虚读：一个事务读到另一个事务已提交的新插入的数据。

4、不可重复读：一个事务读到另一个事务已提交的更新数据。

5、第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新。

数据库系统采用锁来实现事务的隔离性。锁的基本原理如下：

1、当一个事务访问数据库资源时，如果执行select语句，必须先获得共享锁；如果执行insert、update、delete语句，必须获得独占锁，这些锁用于锁定被操纵的资源。

2、当第二个事务也要访问数据库中的相同资源时，如果执行select语句，也必须获得共享锁，如果执行insert、update、delete语句，也必须获得独占锁。此时，第二个事务要根据锁的类型来判断应该等待第一个事务解除对资源的锁定，还是可以立刻获得锁。

以下是各种情况：

资源上已经放置锁	第二个事务进行读操作	第二个事务进行写操作
无	立即获得共享锁	立即获得独占锁
共享锁	立即获得共享锁	等待第一个事务解除独占锁
独占锁	等待第一个事务解除独占锁	等待第一个事务解除独占锁

锁机制可以有效地解决各种并发问题，但是它会影响并发的性能。并发性能越好，数据库系统同时为各种客户提供服务的能力就越强。当一个事务锁定资源时候，其他事务必须等待，这样就降低了数据库系统同时响应客户程序的速度。因此我们要在事务的隔离性和并发性之间做权衡。数据库系统提供了4种事务隔离级别：

1、Serializable：串行化。

一个事物已经访问数据库，那么另一个事务必须停下来等待，等第一个事务结束后才能恢复运行。

2、Repeatable Read：可重复读。

一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他事务已经提交的对已有记录的更新（能看到insert操作，不能看到update操作）。

3、Read Committed：读取已提交数据。

一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新（能看到insert操作，也能看到update操作）。最常用。

4、Read Uncommitted：读取未提交数据。

一个事物在执行过程中可以看到其他事务没有提交的新插入的记录，而且能够看到其他事务没有提交的对已有记录的更新。

从1到4，隔离级别越来越低，并发性能越来越高。