hibernate中session的获取使用以及其他注意事项
前言：工作时，在同时使用Hibernate的getSession()、getHibernateTemplate()获取Session后进行数据查询时不是出现了"session is close"异常就是出现其他异常问题，痛定思痛，决定收集并整理相关资料，方便今后的使用。
一、session的获取
在hibernate中的Session对象通过SessionFactory来管理，可以通过使用openSession ()、getSession()和getCurrentSession()方法来获取session。
Spring和Hibernate的集成的一个要点就是对事务的支持，openSession、getCurrentSession都是编程式事务（手动设置事务的提交、回滚）中重要的对象，HibernateDaoSupport则提供了更方便的声明式事务支持。（引自：lmdcszh的 由openSession、getCurrentSession和HibernateDaoSupport浅谈Spring对事物的支持）
注：在 SessionFactory 启动的时候， Hibernate 会根据配置创建相应的 CurrentSessionContext ，在 getCurrentSession() 被调用的时候，实际被执行的方法是 CurrentSessionContext.currentSession() 。在 currentSession() 执行时，如果当前 Session 为空， currentSession 会调用 SessionFactory 的 openSession 。
所以 getCurrentSession() 对于 Java EE 来说是更好的获取 Session 的方法。
二、openSession ()、getSession()和getCurrentSession()方法的区别
以下内容引自jpbirdy的文章“Hibernate中的openSession()，getSession() 和 getCurrentSession() 的区别”。讲的非常好，我就不一一细述，文章内容如下：
开发中，使用MyEclipse自动生成的Hibernate DAO类中在对session的获取中，都使用的getSession（MyEclipse8.5之前的版本都是如此）
首先要说明一下这3个方法：
1、openSession 和 getCurrentSession这两个方法是 Hibernate中的sessionFactory中的方法。要获取session只能通过这两个方法获取。
2、getSession这个方法是使用MyEclipse的Hibernate工具时自动生成的方法。进入方法里查看：
public static Session getSession() throws HibernateException {
Session session = (Session) threadLocal.get();//注1
if (session == null || !session.isOpen()) {
if (sessionFactory == null) {
rebuildSessionFactory();//注2
}
session = (sessionFactory != null) ? sessionFactory.openSession(): null;
threadLocal.set(session);
}
return session;
}
很明显，Myeclipse使用的是openSession。所以上述的3个方法，其实也就是openSession和getCurrentSession的区别。
这里简单说明一下openSession 和 getCurrentSession这两个方法的区别。
很容易看出来，openSession每次都是创建一个新的session，而getCurrentSession会查看，如果当前上下文中已经有Session，则直接使用原有的，否则会创建一个新的session。
当然这样说并不是很形象。很多人会理解为，后面一个只是前面的略微优化而已，每次都打开新的也不会出错。当然这样理解并没有完全错误，其实这里的Session使用上没有很大的区别，区别是在于使用openSession时，如果涉及到对数据库的数据的修改（增、删、改），在事务提交之后，session必须手动关闭（session.close()），否则会出错，一般是数据已经保存进数据库，但使用Hibernate再次查询数据时并没有显示新的值。而getCurrentSession在事务提交后会自动关闭当前session。所以，一般推荐使用getCurrentSession，这样需要我们关心的内容就更少，而且更不容易出错。 当然，MyEclipse也不会放着高级的东西不用的，仔细查看上面的代码，发现在openSession之前，session会先从threadLocal中获取，这里的threadLocal就可以类比为getCurrentSession中配置的thread，所以，可以认为MyEclipse是在openSession之前已经实现了从线程中获取上下文的Session，所以直接使用MyEclipse生成的getSession的功能类似getCurrentSession，但是测试后发现，getSession在提交事务之后，并没有自动关闭，仍然需要手动关闭。
为什么MyEclipse不使用getCurrentSession呢？
查看生成的DAO类可以发现，MyEclipse生成的是没有和事务相关的操作的，当然在进行save、update、delete操作时必须手动添加事务开始和事务提交，所以这里在提交事务之后必须手动关闭session。而进行数据库查找操作时，openSession是不需要提交事务的。getCurrentSession则必须要打开一个新的事务，否则会报createQuery is not valid without active transaction错误。
从简化操作的角度，直接使用MyEclipse的方法更为简单，但要记住增删改操作必须手动添加事务，并在操作结束后关闭session。
注释：
注1-ThreadLocal
其实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，而是threadlocalvariable(线程局部变量)。
线程局部变量(ThreadLocal)其实的功用非常简单，就是为每一个使用该变量的线程都提供一个变量值的副本，是Java中一种较为特殊的线程绑定机制，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。
常用API:
T get( ) --返回此线程局部变量的当前线程副本中的值，如果这是线程第一次调用该方法，则创建并初始化此副本。
void set(T value) --将此线程局部变量的当前线程副本中的值设置为指定值。许多应用程序不需要这项功能，它们只依赖于 initialValue() 方法来设置线程局部变量的值。
（引自：深入研究java.lang.ThreadLocal类）
注2-rebuildSessionFactory 重新加载hibernate，在HibernateUtil中的具体实现如下：
public static void rebuildSessionFactory() {
log.debug("Using current Configuration to rebuild SessionFactory");
rebuildSessionFactory(configuration);
}
public static void rebuildSessionFactory(Configuration cfg) {
log.debug("Rebuilding the SessionFactory from given Configuration");
if (sessionFactory != null && !sessionFactory.isClosed())
sessionFactory.close();
if (cfg.getProperty(Environment.SESSION_FACTORY_NAME) != null) {
log.debug("Managing SessionFactory in JNDI");
cfg.buildSessionFactory();
} else {
log.debug("Holding SessionFactory in static variable");
sessionFactory = cfg.buildSessionFactory();
}
configuration = cfg;
}
HibernateUtil 源码：请点击!
总结：
1、openSession和getCurrentSession的根本区别在于有没有绑定当前线程，所以，使用方法有差异：
* openSession 没有绑定当前线程，所以，使用完后必须关闭。重新建立一个新的session。
* currentSession 和当前线程绑定,在事务结束后会自动关闭。使用当前的session。
2、在一个应用程序中，如果DAO 层使用Spring 的hibernate 模板，通过Spring 来控制session 的生命周期，则首选getCurrentSession ()。
以下内容引自lmdcszh的由openSession、getCurrentSession和HibernateDaoSupport浅谈Spring对事物的支持，想看原文的可直接点击此链接。
三、事务的边界和传播
通常情况下事务的边界需要设置在业务逻辑处理层中，但是若在一个业务中涉及到多个业务逻辑层之间的方法，且这些方法需要在同一个事务中运行，那这就涉及到了事务的传播性。
如果使用openSession，就要在dao层的方法中传递session，而这种做法是很糟糕的，首先增加了参数的个数，另外，方法是否需要事务，完全是可以当做一种独立的服务抽离出的。
因为currentSession是线程级别的，所以，只要业务逻辑方法在同一个线程中，就不会担心上面的问题。这也是currentSession的一个优越处之一。
使用currentSession：
1.在配置文件中将线程配置成Thread级别的。
<property name="hibernate.current_session_context_class">thread</property>
2.调用sessionFactory的getCurrentSession方法：
publicvoid addUser(User user) {
Session session = null;
try {
session =this.getSessionFactory().getCurrentSession();
session.beginTransaction();
session.save(user);
//记录操作日志，此处略
session.getTransaction().commit();
}catch(Exception e) {
e.printStackTrace();
session.getTransaction().rollback();
}
}
使用openSession:
public void addUser(User user) {
Session session = null;
try{
session= this.getSession();
session.beginTransaction();
// 若干操作…………
session.getTransaction().commit();
}catch(Exceptione) {
e.printStackTrace();
session.getTransaction().rollback();
}finally{
HibernateUtils.closeSession(session);
}
使用HibernateDaoSupport声明式事务：即使用this.getHibernateTemplate()方法时可调用的方法，如save、update等。
Spring与Hibernate的集成使用最多的是HibernateDaoSupport，它对session的获取以及事务做了进一步的封装,只需要关注dao的实现,而不用担心某个地方的事务是否关闭。
四、关于异常与事务回滚
Spring在遇到运行期异常(继承了RuntimeException)的时候才会回滚，如果是Exception(如用户输入密码错误)抛出就好，事务会继续往下进行。
Spring对异常的处理的灵活性还是比较高的,可以配置遇到某个Exception进行回滚，某个RuntimeException不回滚,但是对于EJB就没有这么灵活了,EJB相当于是固定的套餐。
不会回滚:
public void addUser(User user) throws Exception {
this.getHibernateTemplate().save(user);
//若干操作……
throw new Exception();
}
回滚:
public void addUser(User user) {
this.getHibernateTemplate().save(user);
//若干操作……
throw new RuntimeException();
}
五、事务传播特性
为了保证调用的业务逻辑方法都使用同一个事务，通常都使用REQUIRED这个级别，它表示：如果上一个方法中有事务，就直接使用，如果没有，就创建一个事务，这样，一旦事务创建了后，后续调用的方法就不会再创建。
其他的事务传播特性见下表：
六、Spring事务的隔离级别
1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别。
另外四个与JDBC的隔离级别相对应。
2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
这种隔离级别会产生脏读，不可重复读和幻像读。
3. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据
4. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
5. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
除了防止脏读，不可重复读外，还避免了幻像读。
事务隔离级别主要应用在对大数据的处理方面，与锁的机制是密不可分的，这里不赘述。