标签:
比如在同一线程内用同一个session。在同一方法内用同一session,这样我们就能够用session里面缓存好的数据。但。我想说的不是缓存,且听我一一道来。
就是我明明配置好了spring管理hibernate事务了,当我在dao中运行hibernate的方法时。如save。delete,update,createQuery,总是说不能在没有活动的事务中运行(org.hibernate.HibernateException: createSQLQuery is not valid without active transaction)。立刻上google查。一无所获。曾几度怀疑是否配置写出了。dao或service写错了,改来改去的依然存在问题。当时相当郁闷啊,想啊,你spring不是帮我管理事务么?你不自己主动开启事务啊,还要我手动开启啊。立刻查spring文档。从中文到英文。没发现什么有參考价值的线索,真是相当的打击。代码乱改一通。发现用spring的hibernatetemplate来进行数据操作又正常无比。不死心的去查了hibernate的doc,一个不留神给哥发现了一个冗长的配置属性:hibernate.current_session_context_class。心里巨爽无比,就是你丫啦。小样的。哥把你灭了。
从 3.0.1 版本号開始,Hibernate 添加了SessionFactory.getCurrentSession() 方法。
一開始,它假定了採用 JTA 事务。JTA 事务定义了当前 session 的范围和上下文(scope 和 context)。由于有好几个独立的 JTA TransactionManager 实现稳定可用,不论是否被部署到一个 J2EE 容器中,大多数(假若不是全部的)应用程序都应该採用 JTA 事务管理。基于这一点。採用 JTA 的上下文相关的会话能够满足你一切须要。
按我简单的理解就是将getCurrentSession()返回的session绑定到当前执行线程中。比較专业的说法是此session的上下文是thread,但不是spring已经托管的那个Session对象。再用哥那大腿想了几下,瞬间了解了一些。所以获取的session是在spring代理的上下文之外的的当前线程之中。所以此session并不是事务管理器代理的那个session,不会自己主动开启事务。依据官方提示:第三方框架提供了基于代理(proxy)或者基于拦截器(interception)的上下文相关的会话的管理,所以把hibernate.current_session_context_class设置删除了。一切又回到当初风平浪静的日子了。
编程异常——假设你报createSQLQuery is not valid without active transaction,...
标签:
原文地址:http://www.cnblogs.com/mengfanrong/p/5346928.html