Re: [Springframework-developer] OpenSessionInViewFilter ideas

[<jue...@we...>]

Essentially, I recommend to avoid OpenSessionInViewFilter as far as =
possible, sticking to per-transaction Sessions. In that case, your =
strategy of catching OptimisticLockingFailureException and retrying will =
work without any issues, in a natural fashion. This is how transactions =
usually behave in Spring: The Session will be closed at transaction =
completion. OpenSessionInViewFilter breaks that principle for the sake =
of using a single Session for the entire request; this is a tradeoff =
that the application developer can choose.
=20
The central problem is that safely relying on the classic Open Session =
in View pattern for lazy loading in the view requires that *all* data =
access operations have been performed on the single Session. If you =
discard the Session mid-way and bind a new one, objects that have been =
loaded by the first Session and end up in the model for the view (for =
example, some reference data) will *not* be able to lazily load data =
anymore. While this may work in some cases, it is not generally =
reliable.
=20
To get both transaction-scoped Sessions *and* lazy loading in views, we =
would need to provide a different mechanism. For example, we could =
register all transactional Sessions to be closed at request completion: =
Each transaction would work with its own Session; the difference is that =
those Sessions will not be closed at transaction completion but rather =
at request completion, to allow for lazy loading. This requires =
implementing a new mechanism that gathers those Sessions, without tying =
HibernateTransactionManager to web concepts: not trivial, but possible.
=20
Note that the whole problem wouldn't exist if Hibernate would not tie =
lazy loading in persistent objects to the original Session that loaded =
them. As a counterexample, take OJB: Lazy loading simply fetches a new =
JDBC Connection there if the original PersistenceBroker is already =
closed. There is no need for an Open PersistenceBroker in View pattern =
in the first place! JDO requires the PersistenceManager to still be =
open, like Hibernate, but can at least correctly reset objects in case =
of a transaction rollback (it rolls back *object state* too, not just =
database state), not needing to discard the PersistenceBroker in that =
case.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Chris Richardson
Gesendet: Di 06.07.2004 22:01
An: spr...@li...
Betreff: Re: [Springframework-developer] OpenSessionInViewFilter ideas



On Thu, 24 Jun 2004 18:03:56 -0700, Norris, Tyson
<tys...@be...> wrote:
> Hi Folks -
> We have been running into problems with migrating an existing CMT EJB
> application to use OpenSessionInViewFilter, and here are a couple
> thoughts on the subject.
>
> The basic problem is that when a session is created, then a =
transaction
> is initiated and uses that session, if the transaction rolls back, how
> can we still access the initial session created in the filter?
>
> Currently the same session is used after entering the transaction. =
This
> is a problem for us using weblogic, since weblogic datasource become
> useless after a transaction rolls back (or commits), but I think this =
is
> also general practice for hibernate users to close the session on
> rollback:
> "If you rollback the transaction you should immediately close and
> discard the current session to ensure that Hibernate's internal state =
is
> consistent."
>
> So, what to do? Would it be desirable to build into =
SessionFactoryUtils
> the ability to generate a new session for each new transaction?
>

This functionality would be very useful.
In my application I want to rollback and retry the transaction if an
optimistic locking failure occurs, i.e Hibernate throws a
StaleObjectStateException.

I have an interceptor that runs before the TransactionInterceptor that
catches the OptimisticLockingFailureException and redoes the call. It
needs to close the existing Session and open a new one. I wrote some
code that does an TransactionSynchronizationManager.unbindResource()
following be a close, an open and then a bindResource(). It appears to
work but it would be nice if this was handled by SessionFactoryUtils

Chris


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer