public class OpenSessionInViewInterceptor extends HibernateAccessor implements AsyncWebRequestInterceptor
Sessionto the thread for the entire processing of the request.
This class is a concrete expression of the "Open Session in View" pattern, which is a pattern that allows for the lazy loading of associations in web views despite the original transactions already being completed.
This interceptor makes Hibernate
Sessions available via the current
thread, which will be autodetected by transaction managers. It is suitable for
service layer transactions via
JtaTransactionManager as well as for
non-transactional execution (if configured appropriately).
NOTE: This interceptor will by default not flush the Hibernate
Session, with the flush mode being set to
It assumes that it will be used in combination with service layer transactions
that handle the flushing: the active transaction manager will temporarily change
the flush mode to
FlushMode.AUTO during a read-write transaction,
with the flush mode reset to
FlushMode.NEVER at the end of each
transaction. If you intend to use this interceptor without transactions, consider
changing the default flush mode (through the
In contrast to
OpenSessionInViewFilter, this interceptor is
configured in a Spring application context and can thus take advantage of bean
wiring. It inherits common Hibernate configuration properties from
to be configured in a bean definition.
WARNING: Applying this interceptor to existing logic can cause issues
that have not appeared before, through the use of a single Hibernate
Session for the processing of an entire request. In particular, the
reassociation of persistent objects with a Hibernate
Session has to
occur at the very beginning of request processing, to avoid clashes with already
loaded instances of the same objects.
Alternatively, turn this interceptor into deferred close mode, by specifying "singleSession"="false": It will not use a single session per request then, but rather let each data access operation or transaction use its own session (as would be the case without Open Session in View). Each of those sessions will be registered for deferred close though, which will actually be processed at request completion.
A single session per request allows for the most efficient first-level caching,
but can cause side effects, for example on
saveOrUpdate or when
continuing after a rolled-back transaction. The deferred close strategy is as safe
as no Open Session in View in that respect, while still allowing for lazy loading
in views (but not providing a first-level cache for the entire request).
|Modifier and Type||Class and Description|
Bind and unbind the Hibernate
|Modifier and Type||Field and Description|
Suffix that gets appended to the
|Constructor and Description|
Create a new
|Modifier and Type||Method and Description|
Unbind the Hibernate
Called instead of
Return the name of the request attribute that identifies that a request is already intercepted.
Return whether to use a single session for each request.
Flush the Hibernate
Open a new Hibernate
Set whether to use a single session for each request.
afterPropertiesSet, applyFlushMode, convertHibernateAccessException, convertJdbcAccessException, convertJdbcAccessException, disableFilters, enableFilters, flushIfNecessary, getDefaultJdbcExceptionTranslator, getEntityInterceptor, getFilterNames, getFlushMode, getJdbcExceptionTranslator, getSessionFactory, setBeanFactory, setEntityInterceptor, setEntityInterceptorBeanName, setFilterName, setFilterNames, setFlushMode, setFlushModeName, setJdbcExceptionTranslator, setSessionFactory
public static final java.lang.String PARTICIPATE_SUFFIX
toString()representation for the "participate in existing session handling" request attribute.
private boolean singleSession
OpenSessionInViewInterceptor, turning the default flushMode to
public void setSingleSession(boolean singleSession)
If set to false, each data access operation or transaction will use its own session (like without Open Session in View). Each of those sessions will be registered for deferred close, though, actually processed at request completion.
protected boolean isSingleSession()
public void preHandle(WebRequest request) throws DataAccessException
Sessionaccording to the settings of this
HibernateAccessorand bind it to the thread via the
request- the current web request
public void postHandle(WebRequest request, ModelMap model) throws DataAccessException
Sessionbefore view rendering, if necessary.
Note that this just applies in
single session mode!
The default is
FLUSH_NEVER to avoid this extra flushing,
assuming that service layer transactions have flushed their changes on commit.
request- the current web request
model- the map of model objects that will be exposed to the view (may be
null). Can be used to analyze the exposed model and/or to add further model attributes, if desired.
public void afterCompletion(WebRequest request, java.lang.Exception ex) throws DataAccessException
Sessionfrom the thread and close it (in single session mode), or process deferred close for all sessions that have been opened during the current request (in deferred close mode).
public void afterConcurrentHandlingStarted(WebRequest request)
afterCompletion, when the the handler started handling the request concurrently.
private boolean decrementParticipateCount(WebRequest request)
protected java.lang.String getParticipateAttributeName()
The default implementation takes the
SessionFactory instance and appends
private boolean applySessionBindingInterceptor(WebAsyncManager asyncManager, java.lang.String key)