Spring Portlet HandlerInterceptor that binds a Hibernate Session to the thread for the
entire processing of the render request. Intended for the "Open Session in View" pattern,
i.e. to allow for lazy loading in web views despite the original transactions
already being completed.
This interceptor works similar to the AOP HibernateInterceptor: It just makes
Hibernate Sessions available via the thread. It is suitable for non-transactional
execution but also for middle tier transactions via HibernateTransactionManager
or JtaTransactionManager. In the latter case, Sessions pre-bound by this interceptor
will automatically be used for the transactions and flushed accordingly.
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 if 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).
NOTE: This interceptor will by default not flush the Hibernate session,
as it assumes to be used in combination with business layer transactions that care
for the flushing, or HibernateAccessors with flushMode FLUSH_EAGER. If you want this
interceptor to flush after the handler has been invoked but before view rendering,
set the flushMode of this interceptor to FLUSH_AUTO in such a scenario. Note that
the flushMode of this interceptor will just apply in single session mode!
This interceptor works similar to the AOP HibernateInterceptor: It just makes Hibernate Sessions available via the thread. It is suitable for non-transactional execution but also for middle tier transactions via HibernateTransactionManager or JtaTransactionManager. In the latter case, Sessions pre-bound by this interceptor will automatically be used for the transactions and flushed accordingly.
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 if 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).
NOTE: This interceptor will by default not flush the Hibernate session, as it assumes to be used in combination with business layer transactions that care for the flushing, or HibernateAccessors with flushMode FLUSH_EAGER. If you want this interceptor to flush after the handler has been invoked but before view rendering, set the flushMode of this interceptor to FLUSH_AUTO in such a scenario. Note that the flushMode of this interceptor will just apply in single session mode!