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

Brought to you by: colins, jhoeller, johnsonr, robharrop, trevormarshall

springframework-developer

[Springframework-developer] Potentialt dangerous hibernate Session reuse

From: Per O. <po...@no...> - 2005-02-11 08:00:42

Hi,

I have a comment/question to how spring handles threadlocal bound session in 
case of exception and rollback.

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.

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.

Then, in spring release 1.1.2, I saw this was fixed in 
HibernateTransactionManager (v1.40) by calling session.clear() when an 
exception occurs.

Even though this works with current hibernate release, I find this to be a bit 
insecure. The hibernate docs on Session class explicitly says:

   " 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."

On the other hand, apidocs for clear() says:

  "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"

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().

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.

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.

What are your thoughts on this?

Regards, Per


-- 
Per Olesen @ Nordija A/S - www.nordija.com - main#: +45 70 20 25 10
email: po...@no... - cell#: +45 23 38 95 81

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

From: James C. <jim...@do...> - 2005-02-14 14:07:14

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