An understanding of session and thread binding in Hibernate 1. There is one in the Hibernate3 hibernate.cfg.xml configuration file:
<propertyname= "Current_session_context_class" >thread</property>
The official explanation to him is as follows:
First, as long as you hold sessionfactory, you can call this method at any time, any place: Getcurrentsession ()
Method always returns the "current" unit of work. Remember that we adjusted this configuration option to "thread" in Hibernate.cfg.xml.
Therefore, the scope of the current unit of work is the Java thread that is currently executing our application. However, this is not always true.
When the session is first used, or when getcurrentsession () is first called, its life cycle begins.
It is then bound to the current thread by hibernate. When the transaction is finished, either commit or rollback, hibernate will
The session is stripped from the current thread and closes it. If you call Getcurrentsession () again, you will get a new session and start a new unit of work.
Perhaps some of the above explanations do not understand.
First explain the thread binding, why the session and thread binding it.
For example, we're going to write a servlet to implement session reuse
public class Testservlet extends HttpServlet
{
Privateorg.hibernate.Session thisthreadssession;
Public Voiddoget (...) throws ...
{
Thisthreadssession = Session opened in the current thread ();
DoSomething (); {//Access operation based on current session}
Thisthreadssession.flush ();
}
}
Note that in general, there is only one instance per servlet in the application server, so in the case above, multithreading concurrently calls the
The only instance of Testservlet, where the thisthreadssession will be reset by each thread, the problem is a thread
May access the session to the C thread.
The workaround is to use the threadlocal thread: He maintains a private variable space for each thread, that is, the key that maintains a private map,map for each thread in the JVM is the current thread ID. The value is an instance of the object saved by the Threadlocal.set method (this is the session instance of hibernate that the thread opened)
The implementation code is as follows:
public class Testservlet extends HttpServlet
{
Private ThreadLocal Localobjectinthisthread = Newthreadlocal ();
public void doget (...) throws ...
{
Localobjectinthisthread.set (Org.hibernate.Session The session that is already open in the current thread);
DoSomething ();
}
public void DoSomething ()
{
Org.hibernate.Session thisthreadssession = (org.hibernate.Session)
Localobjectinthisthread.get ();
Access operations based on the current session
......
Thisthreadssession.flush ();
}
}
From the Code, Localobjectinthisthread.get () gets a session that is always the session of the current thread, which is called thread binding.
2. Hibernate's official sample code Sessionfactoryutil or the tool class automatically generated by Eclipse's Hibernate plugin
Hibernatesessionfactory (Note that there is a static function in the org.hibernate.SessionFactory in Hibernate.jar) getsession
public static Session GetSession () throws Hibernateexception
{
Session Session = (session) Threadlocal.get ();
if (session== null | |!session.isopen ())
{
if (sessionfactory = = null)
{
Rebuildsessionfactory ();
}
Session = (Sessionfactory! = null)? Sessionfactory.opensession
(): null;
Threadlocal.set (session);
}
return session;
}
From the previous analysis, it is easy to see that she returned a thread-bound session
So what is the difference between this getsession () method and the Sessionfactory.getcurrentsession () mentioned earlier?
The same thing is: when you first call getsession () or sessionfactory.getcurrentsession (), open a new session and bind it to the current thread.
The difference is: When a transaction is commit, the session returned by Sessionfactory.getcurrentsession () is automatically closed, and
The session returned by GetSession () is still open and needs to be explicitly closed (perhaps for ease of reuse within threads).
Finally read the official explanation of the beginning again, I believe there will be a deeper understanding:
First, as long as you hold sessionfactory, you can call this method at any time, any place: Getcurrentsession ()
Method always returns the "current" unit of work. Remember that we adjusted this configuration option to "thread" in Hibernate.cfg.xml. Therefore, the scope of the current unit of work is the Java thread that is currently executing our application. However, this is not always true. When the session is first used, or when getcurrentsession () is first called, its life cycle begins. It is then bound to the current thread by hibernate. Hibernate also strips the session from the current thread and closes it when the transaction is finished, either committed or rolled back. If you call Getcurrentsession () again, you will get a new session and start a new unit of work.
