Spring web request interceptor that binds a Hibernate Session to the thread for the
entire processing of the request. Intended for the "Open Session in View" pattern,
that is, to allow for lazy loading 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 set to FlushMode.NEVER . It assumes to be used
in combination with service layer transactions that care for 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 "flushMode" property).
In contrast to
OpenSessionInViewFilter , this interceptor is set up
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 will 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
(like without Open Session in View). Each of those sessions will be registered
for deferred close, though, actually processed at request completion.
A single session per request allows for 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 |