Hibernate事物控制与管理

   数据库事务必须具备ACID的特征(Atomic原子性,Consistency一致性,Isolation隔离性,Durability持久性)数据库操作过程中可能出现的3种不确定情况:
    1. 脏读取(Dirty Reads):一个事务读取了另一个并行事务未提交的数据。
    2. 不可重复读取(Non-repeatable Reads):一个事务再次读取之前的数据时,得到的数据不一致,被另一个已提交的事务修改。
    3. 虚读(Phantom Reads):一个事务重新执行一个查询,返回的记录中包含了因为其他最近提交的事务而产生的新记录。
    标准SQL规范中,为了避免上面3种情况的出现,定义了4个事务隔离等级:
    1. Read Uncommitted:最低等级的事务隔离,仅仅保证了读取过程中不会读取到非法数据。上诉3种不确定情况均有可能发生。
    2. Read Committed:大多数主流数据库的默认事务等级,保证了一个事务不会读到另一个并行事务已修改但未提交的数据,避免了“脏读取”。该级别适用于大多数系统。
    3. Repeatable Read:保证了一个事务不会修改已经由另一个事务读取但未提交(回滚)的数据。避免了“脏读取”和“不可重复读取”的情况,但是带来了更多的性能损失。
    4. Serializable:最高等级的事务隔离,上面3种不确定情况都将被规避。这个级别将模拟事务的串行执行。
   
一、Hibernate事物控制
    Hibernate为了避免脏读、泛读、不可重复读等可能会违背数据ACID原则的操作设置了两套策略对事物进行控制(一般结合使用):
    1、 在Hibernate配置文件中设置隔离级别(从宏观上控制)
    JDBC连接数据库使用的是默认隔离级别,即读操作已提交(Read Committed)和可重读(Repeatable Read)。在Hibernate的配置文件hibernate.properties中,可以修改隔离级别:
   
hibernate.connection.isolation 4

    也可以在配置文件hibernate.cfg.xml中加入以下代码:
    
<session-factory>
  ……         
   //把隔离级别设置为4
  <property name="hibernate.connection.isolation">4</property>
</session-factory>

     Hibernate事务的隔离级别的数字意义如下。
    
1:读操作未提交(Read Uncommitted)
2:读操作已提交(Read Committed)
4:可重读(Repeatable Read)
8:可串行化(Serializable)

    2、 在代码上提供两种锁机制:悲观锁机制与乐观锁机制(从微观上控制)

二、Hibernate事物管理
  Hibernate是JDBC的轻量级封装,本身并不具备事务管理能力,在事务管理层Hibernate将其委托给底层的JDBC或者JTA,以实现事务的管理和调度.
  Hibernate的 默认事务处理机制基于JDBCTransaction,也可以通过配置文件设定采用JTA作为事务管理实现:
  <hibernate-configuration> 
        <session-factory> 
    …… 
             <property name = "hibernate.transaction.factory_class"> 
               net.sf.hibernate.transaction.JTATransactionFactory 
             </property>
    </session-factory> 
   </hibernate-configuration> 

1、基于JDBC的事务管理
   Hibernate对于JDBC事务的封装非常简单。例如:
   public void saveUser(){
     Session session = sessionFactory.openSession();
     Transaction tx = session.beginTransaction();
     session.save(user);
     tx.commit();
     session.close();
   }
   必须在session.close()之前commit或者rollback

   这里要注意的是,在sessionFactory.openSession()中,Hibernate会初始化数据库连接,与此同时,将其 AutoCommit设为关闭状态,这就是说,从SessionFactory获得的session其自动提交属性就已经被关闭了,下面的代码不会对事务性数据库产生任何效果。
session=sessionFactory.openSession(); 
   session.save(user); 
   session.close(); 

   如果要使得代码真正作用到数据库,必须显示的调用Transaction指令提交事物

2、基于JTA的事务管理
   JTA提供了跨Session的事务管理能力,这是与JDBCTransaction最大的差异。
public void saveUser(){
     Session session = sessionFactory.openSession();
     Transaction tx = session.beginTransaction();
    
     session.save(user);
     session.close();
    
     Session session1 = sessionFactory.openSession();
     session1.save(user1);
     session.close();
    
     tx.commit();
}
  commit和rollback可以在session.close()之后执行.同时应该注意的一点是,事务是不能嵌套的,在使用jta的事务的情况下,如果要让一个事务跨越两个session,则必须在两个session的外层开始事务和完成事务。而不能再在session内部开始事务和完成事务。

   JDBC 事务由Connection管理,也就是说,事务管理实际上是在JDBC Connection中实现,事务周期限于Connection生命周期之内,对于基于JDBC Transaction的Hibernate事务管理机制,事务管理在Session所依托的JDBC Connection中实现,事务周期限于Session的生命周期。
   JTA事务管理由JTA容器实现,JTA容器对当前加入事务的众多Connection进行调度,实现其事务性要求,JTA的事务周期可横跨多个JDBC Connection生命周期,同样,对基于JTA事务的Hibernate,JTA事务横跨多个Session。需要注意的是,参与JTA事务的 Connection需避免对事务管理进行干涉,如果采用JTA Transaction,就不应该再调用Hibernate的Transaction功能。

   特别注意:如果使用了JTA事务,则不能再用在JDBC式的事务来管理每个Session的操作,否则会出错。为了程序的的通用性,一般来说,都是使用 JTA事务来构建应用,这使用任何环境。当然,也可以使用事务代理为每个JDBC的操作方法加入事务控制。这样也为程序以后移植到JTA容器事务上带来很大方便。其实现在可以使用Spring的事务管理,与Hibernate结合的非常完美。   
*****************************************   
hibernate配置正确的情况下:   
    
      在服务层上:   
                  一:如果通过HibernateDaoSupport来getSession  那么 这个session当一个方法结束的时候 就关闭了   
                  二:如果通过HibenateDAOSupport 来getSessionFactory在opensession()那么就是   方法结束后不会关闭session需要自己手动的关闭   
                  三:如果采用的是HibernateTemplate的hbiernatecallback 里面的session是当do..方法结束 就关闭session(不代表 马上就提交事务 这里以后讨论)   
    
  如果 没有配置正确:包括改业务逻辑 没有被spring的事务控制控制 则 上诉 不适用  

你可能感兴趣的:(spring,Hibernate,xml,jdbc,配置管理)