< turn > If you quote createsqlquery is not valid without active transaction, see here

Many times when we use Hibernate's session, we keep the session unique in a running environment. For example, in the same line range with the same session, in the same method with the same session, so that we can use the session to cache good data. But, what I want to say is not the cache, and listen to my one by one Tao.
Recently tried spring3.0.2+struts2.18+hibernate3.3.2 learning to build a Web project, there has been a rather depressing problem. Is that I've configured spring to manage hibernate transactions, When I perform hibernate methods in DAO, such as save,delete,update,createquery, I always say that I cannot execute in a transaction that is not active (org.hibernate.HibernateException: Createsqlquery is not valid without active transaction). Immediately on Google search, nothing. There have been several doubts whether the configuration is written, DAO or service is wrong, changed to change the problem still exists. At that time quite depressed ah, think Ah, you spring is not to help me manage affairs? You do not automatically open the transaction ah, and I have to manually open AH. Immediately check the spring documents, from Chinese to English, did not find any reference value of clues, it is quite a blow. Code to change one pass, found that using spring's hibernatetemplate to perform data operation is extremely normal. Do not forget to check the Hibernate doc, an inattentive to brother found a lengthy configuration properties: Hibernate.current_session_context_class. Your heart is so great that you are the one. Sample, brother put you out.
What does Hibernate.current_session_context_class do with it? In layman's terms, it is the configuration session bound to a running environment, for example, from the same thread with Getcurrentsession () The session is the same, there is no session automatically create a return to you. The problem is here, as the official documentation says:

Most applications that use Hibernate require some form of "context-sensitive" sessions, with specific sessions throughout the
is always valid within the context range. However, it is often difficult for different types of applications to make the next definition of this "context"; different contexts define different scopes for the concept of "current".prior to version 3.0, programs using Hibernate either adopted a self-written ThreadLocal-based context session, either using an auxiliary class such as Hibernateutil, or using a third-party framework (such as Spring or Pico), which provides a context-sensitive session based on agent (proxy) or interceptor (interception). Starting with version 3.0.1, Hibernate adds the Sessionfactory.getcurrentsession () method. At first, it assumes that the JTA transaction is used, and the JTA transaction defines the scope and context of the current session (scopes and contexts). Because there are several independent JTA TransactionManager to achieve stable availability, whether or not deployed in a Java EE container,
Most (if not all) applications should adopt JTA transaction management. Based on this, a context-sensitive session with JTA can meet all your needs.

to see my configuration again, the value of Hibernate.current_session_context_class is set to thread. As I have simply understood, the session returned by Getcurrentsession () is bound to the current running thread. The more professional argument is that the context of this session is thread, but not the session object that spring has hosted. Again with brother that thigh thought a few, instantly learned some. So the session that gets is in the current thread outside the context of the spring proxy, so this session is not the session of the transaction manager agent and does not automatically open the transaction. According to the official tip: The third-party framework provides the management of a context-sensitive session based on proxy or interceptor (interception), so the hibernate.current_session_context_ Class settings removed , and everything went back to the calm days.

Refer to http://justsee.iteye.com/blog/1061576, finally understand the causes and consequences of this problem. Excerpts are as follows:

The sessionfactory configuration file in Ssh2 should be hibernate.current_session_context_ The class is set to Org.springframework.orm.hibernate3.SpringSessionContext (default for this value) and the spring management transaction is applied.

If the <prop key= "Hibernate.current_session_context_class" >thread</prop> will report an exception,

The reason is still the hibernate.current_session_context_class problem in spring

In the Spring class Localsessionfactorybean source code, method Buildsessionfactory will Hibernate.current_session_context_ Class set to Org.springframework.orm.hibernate3.SpringSessionContext

It's been a long time since I met this mistake