Problems encountered:
Scenario 1:
The following error was encountered while using the Sessionfactory Getcurrentsession method, which was checked for the following reasons:
is because the following settings have been forgotten in the Hibernate.cfg.xml file:
Hibernate.current_session_context_class If you are running hibernate in a Web container, add this phrase in Hibernate.cfg.xml:
<property name= "Hibernate.current_session_context_class" >jta</property>
If you are running hibernate in a separate Java application that requires a JDBC connection, this setting:
<property name= "Hibernate.current_session_context_class" >thread</property>
Scenario 2:
In the Sessionfactory configuration file in Ssh2
Hibernate.current_session_context_class should be set to Org.springframework.orm.hibernate3.SpringSessionContext (default for this value)
and apply spring management transactions. If the <prop key= "Hibernate.current_session_context_class" >thread</prop> will report an exception,
So it's a 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
Java code
- if (Isexposetransactionawaresessionfactory ()) {
- //Set Hibernate 3.1+ currentsessioncontext Implementation,
- //providing the spring-managed session as current session.
- //Can be overridden by a custom value for the corresponding Hibernate property.
- Config.setproperty (Environment.current_session_context_class, Springsessioncontext. Class.getname ());
- }
- if (this.jtatransactionmanager! = null) {
- //Set spring-provided JTA TransactionManager as Hibernate property.
- Config.setproperty (Environment.transaction_strategy, jtatransactionfactory. Class.getname ());
- Config.setproperty (Environment.transaction_manager_strategy, Localtransactionmanagerlookup. Class.getname ());
- } Else {
- //Makes the Hibernate Session aware of the presence of a spring-managed transaction.
- //Also sets connection release mode to On_close by default.
- Config.setproperty (Environment.transaction_strategy, springtransactionfactory. Class.getname ());
- }
Knowledge Summary:
Hibernate.current_session_context_class Property
Sessionfactory.getcurrentsession () can do a series of work, and Hibernate binds the session to the current thread when called. Hibernate releases the session from the current thread and closes the session after the transaction has ended. When you call Getcurrentsession () again, you will get a new session and start the series again.
This method is called as follows:
Session session = Hibernateutil.getsessionfactory (). Getcurrentsession ();
Session.begintransaction ();
Event Theevent = new event ();
Theevent.settitle (title);
Theevent.setdate (thedate);
Session.save (theevent);
Session.gettransaction (). commit (); There is no need to close the session. The premise is that the change is set to thread.
In one application, if the DAO layer uses spring's hibernate template to control the session's lifecycle through Spring, getcurrentsession () is preferred.
Most applications that use hibernate require some form of "context-sensitive" session, and a particular session is always valid throughout a specific context. 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). They provide a context-sensitive session based on 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 (scope and contexts). The Hibernate development team strongly believes that because there are several independent JTA TransactionManager that are stable to use, whether or not deployed in a Java EE container, most (if not all) applications should have JTA transaction management. Based on this, the context-sensitive session of the JTA can be used to meet all your needs.
Better yet, from 3.1 onwards, the background implementation of sessionfactory.getcurrentsession () is pluggable. Therefore, we introduced the new extension Interface (Org.hibernate.context.CurrentSessionContext) and the new configuration parameters (Hibernate.current_session_context_class), To plug in the definition of what is the scope and context (scope and context) of the "current session".
See the Javadoc of the Org.hibernate.context.CurrentSessionContext interface, where there is a detailed discussion of its contract. It defines a single method, Currentsession (), which is used by the specific implementation to track the current context session. Hibernate includes three implementations of this interface.
Org.hibernate.context.JTASessionContext-The current session is tracked and defined according to JTA. This is exactly the same as the previous method of supporting JTA only. Please refer to Javadoc for details.
Org.hibernate.context.ThreadLocalSessionContext-The current session is tracked and defined through the currently executing threads. See also Javadoc for details.
Org.hibernate.context.ManagedSessionContext-The current session is tracked and defined through the currently executing threads. However, you need to be responsible for using the static method of this class to bind, or unbind, the session instance, and it does not open (open), flush, or close any session.
The first two implementations both provide a programming model for "one session per database transaction", also called a session per request. The start and end of Hibernate session is controlled by the existence of database transactions. If you are using your own code to manage transactions over pure Java SE, instead of using JTA, it is recommended that you use the Hibernate Transaction API to hide the underlying transaction implementation from your code. If you use JTA, use JTA as an excuse to manage transaction. If you execute code in an EJB container that supports CMT, the transaction boundary is defined declaratively, and you do not need to do any transaction or session management operations in your code.
The Hibernate.current_session_context_class configuration parameter defines which Org.hibernate.context.CurrentSessionContext implementation should be used. Note that, in order to be backwards compatible, if this parameter is not configured, However, there is a org.hibernate.transaction.TransactionManagerLookup configuration, hibernate will use Org.hibernate.context.JTASessionContext. In general, the value of this parameter indicates the full name of the implementation class to be used, but the three built-in implementations can use shorthand, "JTA", "Thread", and "managed".
1. What is the difference between getcurrentsession () and opensession ()?
When the sessionfactory is started, Hibernate creates the corresponding currentsessioncontext based on the configuration, and when Getcurrentsession () is called, The actual method to be executed is currentsessioncontext.currentsession (). When Currentsession () executes, currentsession calls Sessionfactory opensession if the current Session is empty. So Getcurrentsession () is a better way to get a Session for Java EE.
* The session created with Getcurrentsession () is bound to the current thread, while the session created with Opensession () will not
* Sessions created with getcurrentsession () are automatically closed when commit or rollback, and session created with Opensession () must be closed manually
2, using getcurrentsession () need to add the following configuration in the Hibernate.cfg.xml file:
* If you are using a local transaction (JDBC Transaction)
<property name= "Hibernate.current_session_context_class" >thread</property>
* If you are using a global transaction (JTA Transaction)
<property name= "Hibernate.current_session_context_class" >jta</property>
* If you are using the session management mechanism (less commonly used)
<property name= "Hibernate.current_session_context_class" >managed</property>
Facilitates threadlocal mode management session
As early as the launch of Java1.2, a new support was introduced in the Java platform: java.lang.ThreadLocal, which gives us a multi-threaded program
Provides a new option. What is threadlocal? In fact, Threadlocal is not a local implementation version of a thread,
It is thread local variable (thread locals). Perhaps it would be more appropriate to name it Threadlocalvar. Thread local variables (ThreadLocal)
In fact, the function is very simple, is to use a variable for each thread to provide a copy of the variable value, is each thread can independently change their own copy,
And does not conflict with other threads ' replicas. From a thread's point of view, it's as if every thread has exactly one of those variables.
How does threadlocal maintain a copy of a variable for each thread? In fact, the idea of implementation is very simple, there is a map in the Threadlocal class,
A copy of the variable used to store each thread. For example, the following examples are implemented (for simplicity, no collection is considered for generics):
public class Hibernateutil {
public static final ThreadLocal session =new ThreadLocal ();
public static final Sessionfactory sessionfactory;
static {
try {
Sessionfactory = new Configuration (). Configure (). Buildsessionfactory ();
} catch (Throwable ex) {
throw new Exceptionininitializererror (ex);
}
}
public static Session Currentsession () throws Hibernateexception {
Session s = session.get ();
if (s = = null) {
s = sessionfactory.opensession ();
Session.set (s);
}
return s;
}
public static void CloseSession () throws Hibernateexception {
Session s = session.get ();
if (s! = null) {
S.close ();
}
Session.set (NULL);
}
}
The following error was encountered while using Sessionfactory's Getcurrentsession method