Hibernate 数据库事务与隔离级别

数据库事务：事务是指一组相互依赖的操作行为，如银行交易、股票交易或网上购物。事务的成功取决于这些相互依赖的操作行为是否都能执行成功，只要有一个操作行为失败，就意味着整个事务失败。关于事务的一个经典例子就是：A到银行办理转账事务，把100元钱转到B的账号上，这个事务包含以下操作行为： 

（1）从A的账户上减去100元。 

（2）往B的账户上增加100元。

      显然，以上两个操作必须作为一个不可分割的工作单元。假如仅仅第一步操作执行成功，使得Tom的账户上扣除了100元，但是第二步操作执行失败，Jack的账户上没有增加100元，那么整个事务失败。 数据库事务是对现实生活中事务的模拟，它由一组在业务逻辑上相互依赖的SQL语句组成。 

 下面我们一起来看一下数据库事务的生命周期：

                                             

 

这个数据库事务的生命周期图反应出数据库事务的三个边界：

1.事务的开始边界。 

2.事务的正常结束边界（COMMIT）：提交事务，永久保存被事务更新后的数据库状态。 

3.事务的异常结束边界（ROLLBACK）：撤销事务，使数据库退回到执行事务前的初始状态。 

 

其实每个数据库连接都有个全局变量@@autocommit，表示当前的事务模式，它有两个可选值： 0：表示手工提交模式。 1：默认值，表示自动提交模式。 

在自动提交模式下，每个SQL语句都是一个独立的事务。也就是说，每执行一条sql语句，数据库都会自动提交这个事务，当我们用数据库另一个客户端去查询的时候，我们可以看到这个新修改或插入的数据。在手工提交模式下，必须显式指定事务开始边界和结束边界： 

–事务的开始边界：begin 

–提交事务：commit 

–撤销事务：rollback 

 

下面我们来看一下通过JDBC API是如何声明事务边界的：

Connection提供了以下用于控制事务的方法： 

1.setAutoCommit(boolean autoCommit)：设置是否自动提交事务 

2.commit()：提交事务 

3.rollback()：撤销事务 

下面我们看一下具体的应用示例：

 

[java] view plaincopyprint?
  1. try {   
  2. con = java.sql.DriverManager.getConnection(dbUrl,dbUser,dbPwd);   
  3. //设置手工提交事务模式   
  4. con.setAutoCommit(false);   
  5. stmt = con.createStatement();   
  6. //数据库更新操作1   
  7. stmt.executeUpdate("update ACCOUNTS set BALANCE=900 where ID=1 ");   
  8. //数据库更新操作2   
  9. stmt.executeUpdate("update ACCOUNTS set BALANCE=1000 where ID=2 ");   
  10. con.commit(); //提交事务   
  11. }catch(Exception e) {   
  12. try{   
  13. con.rollback(); //操作不成功则撤销事务   
  14. }catch(Exception ex){   
  15. //处理异常   
  16. ……   
  17. }   
  18. //处理异常   
  19. ……   
  20. }finally{…}   



 

 

       看到上边的示例我们可以看出，其实hibernate事务边界就是模仿者JDBC的事务边界来的，其实在hibernate底层的事务管理就是利用的JDBC的事务管理。我们来看一下hibernate事务边界：

1.声明事务的开始边界： 

Transaction tx=session.beginTransaction(); 

2.提交事务: tx.commit(); 

3.撤销事务: tx.rollback(); 

 

       我们在学习JDBC数据库事务管理的时候，重点也是难点的学习了jdbc多个事务并发问题。既然hibernate底层是用JDBC事务管理实现的，那么它也一定存在着多个事务并发的问题。下面我们就具体来看一下：hibernate多个事务并发的并发问题：

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

•脏读：一个事务读到另一事务未提交的更新数据。 

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

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

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

下面我们就脏读来举一个示例：

                                            

 

 

取款事务在T5时刻把存款余额改为900元，支票转账事务在T6时刻查询账户的存款余额为900元，取款事务在T7时刻被撤销，支票转账事务在T8时刻把存款余额改为1000元。 由于支票转账事务查询到了取款事务未提交的更新数据，并且在这个查询结果的基础上进行更新操作，如果取款事务最后被撤销，会导致银行客户损失100元。 

事务隔离级别

关于事务隔离级别，我们来看一下下面的两个图解：

 

                                  

                                    

 

 

由上图可以看出：隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。 对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。 

下面我们就具体来看一下hibernate怎么来配置隔离级别：在Hibernate的配置文件中可以显式的设置隔离级别。每一种隔离级别都对应一个整数： 

1：Read Uncommitted 

2：Read Committed 

4：Repeatable Read 

8：Serializable 

例如，以下代码把hibernate.cfg.xml文件中的隔离级别设为Read Committed： 

hibernate.connection.isolation=2 

或者SpringHibernate.xml文件事务配置的节点isolation="READ_COMMITTED" 即可

对于从数据库连接池中获得的每个连接，Hibernate都会把它改为使用Read Committed隔离级别。

 

Spring在TransactionDefinition接口中定义了五个不同的事务隔离级别：隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量：

 

  • TransactionDefinition.ISOLATION_DEFAULT：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
  • TransactionDefinition.ISOLATION_READ_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读，因此很少使用该隔离级别。
  • TransactionDefinition.ISOLATION_READ_COMMITTED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值。
  • TransactionDefinition.ISOLATION_REPEATABLE_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询，这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。
  • TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

 

在TransactionDefinition接口中定义了七个事务传播行为。

 

所谓事务的传播行为是指，如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

 

  • TransactionDefinition.PROPAGATION_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
  • TransactionDefinition.PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。
  • TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
  • TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
  • TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。
  • TransactionDefinition.PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
  • TransactionDefinition.PROPAGATION_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

 

这里需要指出的是，前面的六种事务传播行为是 Spring 从 EJB 中引入的，他们共享相同的概念。而 PROPAGATION_NESTED是 Spring 所特有的。以 PROPAGATION_NESTED 启动的事务内嵌于外部事务中（如果存在外部事务的话），此时，内嵌事务并不是一个独立的事务，它依赖于外部事务的存在，只有通过外部的事务提交，才能引起内部事务的提交，嵌套的子事务不能单独提交。如果熟悉 JDBC 中的保存点（SavePoint）的概念，那嵌套事务就很容易理解了，其实嵌套的子事务就是保存点的一个应用，一个事务中可以包括多个保存点，每一个嵌套子事务。另外，外部事务的回滚也会导致嵌套子事务的回滚。

 

事务的回滚规则：

 

通常情况下，如果在事务中抛出了未检查异常（继承自 RuntimeException 的异常），则默认将回滚事务。如果没有抛出任何异常，或者抛出了已检查异常，则仍然提交事务。这通常也是大多数开发者希望的处理方式，也是 EJB 中的默认处理方式。但是，我们可以根据需要人为控制事务在抛出某些未检查异常时任然提交事务，或者在抛出某些已检查异常时回滚事务。

 

    • 如果事务是只读的，那么我们可以指定只读属性，使用“readOnly”指定。否则我们不需要设置该属性。
    • 超时属性的取值必须以“TIMEOUT_”开头，后面跟一个int类型的值，表示超时时间，单位是秒。
    • 不影响提交的异常是指，即使事务中抛出了这些类型的异常，事务任然正常提交。必须在每一个异常的名字前面加上“+”。异常的名字可以是类名的一部分。比如“+RuntimeException”、“+tion”等等。
    • 导致回滚的异常是指，当事务中抛出这些类型的异常时，事务将回滚。必须在每一个异常的名字前面加上“-”。异常的名字可以是类名的全部或者部分，比如“-RuntimeException”、“-tion”等等。

      ----------------------------------------------------------------------------------------

      一、丢失或覆盖更新

      当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。
      举例如下：

      事务A和事务B同时修改某行的值，
      事务A将数值改为1并提交 事务B将数值改为2并提交。
      这时数据的值为2，事务A所做的更新将会丢失。 解决办法：对行加锁，只允许并发一个更新事务。 -----------------------------------------------------------------------------------------

      二、脏读：未确认的相关性

      当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。
      举例如下： Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务)  Mary读取自己的工资,发现自己的工资变为了8000，欢天喜地！ 而财务发现操作有误，回滚了事务,Mary的工资又变为了1000
      像这样,Mary记取的工资数8000是一个脏数据。
      解决办法：如果在第一个事务提交前，任何其他事务不可读取其修改过的值，则可以避免该问题。 -------------------------------------------------------------------------------------------

      三、非重复读：不一致的分析

      当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个事务正在读取的数据。然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一行，而且每次信息都由其它事务更改；因而该行被非重复读取。
      在一个事务中前后两次读取的结果并不致，导致了不可重复读。
      举例如下： 在事务1中，Mary 读取了自己的工资为1000,操作并没有完成 在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务. 在事务1中，Mary 再次读取自己的工资时，工资变为了2000
      解决办法：如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。

      --------------------------------------------------------------------------------------------

      四、幻想读

      当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。事务第一次读的行范围显示出其中一行已不复存在于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。

      举例如下：

      目前工资为1000的员工有10人。 事务A读取所有工资为1000的员工。 这时事务B向employee表插入了一条员工记录，工资也为1000
      解决办法：如果在操作事务完成数据处理之前，任何其他事务都不可以添加新数据，则可避免该问题

    •  

      Spring官方参考文档：

      http://static.springsource.org/spring/docs/

 

 

posted @ 2013-08-26 09:59  ixiaofeilee  阅读(3010)  评论(1)  编辑  收藏  举报