RE: [Springframework-developer] Potentialt dangerous hibernate Session reuse

[James C. <jim...@do...>]

It's good that you are considering the exceptional circumstances when =
using
Hibernate. OpenSessionInView (OSIV) is certainly seductive because of =
its
ability to support lazy-loading while the view is being rendered. Once =
you
go beyond the realm of the simple application and have to support
exceptional circumstances, OSIV can be very problematic.

I think you will continue to run into other use cases where OSIV causes
undesirable behavior, as we did. Eventually, we changed our approach and
went with a service layer (in the spirit of an EJB Stateless Session =
Bean)
that clearly demarcates the Hibernate Session and database transactions. =
It
has made our life much easier and more deterministic. The only drawback =
is
that the service layer is responsible for eager loading the lazy-loaded
collections prior to the view rendering.


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Per Olesen
> Sent: Friday, February 11, 2005 3:00 AM
> To: spr...@li...
> Cc: pl...@no...
> Subject: [Springframework-developer] Potentialt dangerous hibernate
> Session reuse
>=20
> Hi,
>=20
> I have a comment/question to how spring handles threadlocal bound =
session
> in
> case of exception and rollback.
>=20
> We are using spring with hibernate and the OpenSessionInViewFilter. =
This
> way
> we get the hibernate Session bound to thread local and reused =
throughout
> request. We've done this from spring 1.0.1 and on.
>=20
> At some point in time, we experienced, that changes on hibernate =
Session
> were
> being committed even though an exception was thrown and spring rolled =
tx
> back. We found this was due to the hibernate session bound to thread =
being
> reused.
>=20
> Then, in spring release 1.1.2, I saw this was fixed in
> HibernateTransactionManager (v1.40) by calling session.clear() when an
> exception occurs.
>=20
> Even though this works with current hibernate release, I find this to =
be a
> bit
> insecure. The hibernate docs on Session class explicitly says:
>=20
>    " If the Session throws an exception, the transaction
>     must be rolled back and the session discarded.
>     The internal state of the Session might not be
>     consistent with the database after the exception occurs."
>=20
> On the other hand, apidocs for clear() says:
>=20
>   "Completely clear the session. Evict all loaded instances
>    and cancel all pending saves, updates and deletions.
>    Do not close open iterators or instances of ScrollableResults"
>=20
> But should we not adhere to the class docs on Session, and throw away =
the
> hibernate session that was bound to threadlocal when an exception =
occurs?
> I
> think that would be most save, would it not? After all, the class docs
> does
> *not* say that you can either throw away session or call clear().
>=20
> In our app, we've made a solution where we extend =
OpenSessionInViewFilter
> and
> override the getSession() method to return a proxied instance which, =
in
> case
> of exception, refuses to dispatch methods to the hibernate session
> anymore.
> This solution will render the session invalid and possibly make the
> application fail, but it will also completely ensure, that the session =
is
> not
> reused for anything in case of exception.
>=20
> But I would much rather, that spring threw away the session from
> threadlocal
> (possibly binding a new one instead?) instead of calling clear(). Or,
> better
> yet, provide me with an option of getting either new session or =
clear()
> call.
>=20
> What are your thoughts on this?
>=20
> Regards, Per
>=20
>=20
> --
> Per Olesen @ Nordija A/S - www.nordija.com - main#: +45 70 20 25 10
> email: po...@no... - cell#: +45 23 38 95 81
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real =
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer