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的事务控制控制 则 上诉 不适用