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 {@link org.springframework.orm.hibernate3.HibernateTransactionManager} or{@link org.springframework.transaction.jta.JtaTransactionManager} as well as fornon-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 {@link #setFlushMode(int) "flushMode"} property).
In contrast to {@link 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 {@link 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 #setSingleSession
@see #setFlushMode
@see OpenSessionInViewFilter
@see org.springframework.orm.hibernate3.HibernateInterceptor
@see org.springframework.orm.hibernate3.HibernateTransactionManager
@see org.springframework.orm.hibernate3.SessionFactoryUtils#getSession
@see org.springframework.transaction.support.TransactionSynchronizationManager