Spring web request interceptor that binds a Hibernate Session to 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
org.springframework.orm.hibernate3.HibernateTransactionManager or
org.springframework.transaction.jta.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 FlushMode.NEVER.
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
OpenSessionInViewInterceptor.setFlushMode(int) "flushMode" property).
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
org.springframework.orm.hibernate3.HibernateAccessor ,
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).
author:
Juergen Hoeller
since:
1.2
See Also: OpenSessionInViewInterceptor.setSingleSession
See Also: OpenSessionInViewInterceptor.setFlushMode
See Also: OpenSessionInViewFilter
See Also: org.springframework.orm.hibernate3.HibernateInterceptor
See Also: org.springframework.orm.hibernate3.HibernateTransactionManager
See Also: org.springframework.orm.hibernate3.SessionFactoryUtils.getSession
See Also: org.springframework.transaction.support.TransactionSynchronizationManager | 