Introduction to Spring's Opensessioninviewfilter

Let's say that hibernate in your app manages its session through spring. If you don't use Opensessioninviewfilter or Opensessioninviewinterceptor in your app. The session will be closed after the transaction is finished.
If you take spring's declarative transaction pattern, it wraps the transaction (AOP) of each method of your proxied object. As follows:

<bean id= "Txproxytemplate" abstract= "true"
class= "Org.springframework.transaction.interceptor.TransactionProxyFactoryBean" >
<property name= "TransactionManager" ref= "TransactionManager"/>
<property name= "Transactionattributes" >
<props>
<prop key= "save*" >PROPAGATION_REQUIRED</prop>
<prop key= "remove*" >PROPAGATION_REQUIRED</prop>
<prop key= "*" >PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>

<bean id= "manager" parent= "Txproxytemplate" >
<property name= "Target" >
<bean class= "Org.appfuse.service.impl.BaseManager" >
<property name= "DAO" ref= "DAO"/>
</bean>
</property>
</bean>
The transaction type propagation_required of the Save * method of the target class Org.appfuse.service.impl.BaseManager, the transaction type of the Remove* method propagation_required
The transaction type of the other method is propagation_required,readonly.
So the feeling is to call the "manager" of the Bean's method after the session is turned off.
If Opensessioninviewfilter or opensessioninviewinterceptor are used in the application, all open sessions are stored in a thread variable. Pass before the thread exits
Opensessioninviewfilter or Opensessioninviewinterceptor disconnect these sessions. Why did you do this? This is primarily to implement the lazy load feature of hibernate. Based on a request
The principle of a hibernate session.

The description of Opensessioninviewfilter in spring is as follows:
It is a Servlet2.3 filter that binds a hibernate session to the line threads the complete request process. The goal is to implement the "Open Session in View" mode.
For example, it allows deferred loading of objects required to display after a transaction commits.

This filter is somewhat similar to Hibernateinterceptor: It is implemented by threading. Whether it's an application without a transaction, or an application with a business-level transaction (via Hibernatetransactionmanager or
Jtatransactionmanager the way it is implemented) is applicable. In the latter case, the transaction automatically takes the session that is bound by the filter to do the related operation and completes the commit operation according to the actual situation.

Warning: If a single hibernate Session is used in your app during a request, in this case, using this filter will produce some problems that were not previously encountered. In particular, it is important to note that
Hibernate session The related operation of re-organizing relationships between persisted objects needs to be done at the very beginning of the request. To avoid conflicts with the same objects that have already been loaded.

Alternatively, we can transfer this filter to the deferred shutdown mode by specifying "singlesession" = "false". This will not use a single session during a request. Every time a data access or transaction-related
The operation uses its own session (a bit like not using open Session in View). These sessions are registered as deferred shutdown mode, even if it is done in this request.

"One session at a time" is very effective for first-level caching, but this can be a side effect. For example, when a saveorupdate or a thing is rolled back, it is as safe as "no Open Session in View".
But it allows for lazy loading.

It looks for the session factory in the context root of spring's web App. It also supports the corresponding bean of the session factory specified by the Init-param element of the "Sessionfactorybeanname" defined in Web. Xml.
Name to find the session factory. The default bean name is "sessionfactory". He avoids problems caused by the initialization order by looking at the sessionfactory of each request (when using Contextloaderservlet
To integrate spring, Spring's application context is initialized after this filter.

By default, this filter does not synchronize Hibernate sessions. This is because it considers the work to be done through business-level transactions. And the Flushmode of Hibernateaccessors is Flush_eager. If you
You want this filter to synchronize the session after the request is completed. You need to overwrite its CloseSession method, in which the session is synchronized before the close session operation of the parent class is called. Also you need to overwrite it with the getsession ()
Method. Returns a session its flushmode is not the default flushmode.never. It is important to note that the getsession () and CloseSession () methods are only called in the single session mode.

A subclass of Opensessioninviewfilter is provided in the Myfaces wiki as follows:
public class Opensessioninviewfilter extends Org.springframework.orm.hibernate3.support.OpenSessionInViewFilter {

/**
* We do a different flushmode than in the codebase
* Here
*/
Protected Session getsession (Sessionfactory sessionfactory) throws Dataaccessresourcefailureexception {
Session session = Sessionfactoryutils.getsession (Sessionfactory, true);
Session.setflushmode (Flushmode.commit);
return session;
}
/**
* We do a explicit flush here just in case
* We don't have a automated flush
*/
protected void CloseSession (Session session, Sessionfactory Factory) {
Session.flush ();
Super.closesession (session, factory);
}
}

Introduction to Spring's Opensessioninviewfilter