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

[Colin S. <col...@ex...>]

Per Olesen wrote:

>Hi Juergen,
>
>Thank you for your comments.
>
>On Monday 14 February 2005 16:13, Juergen Hoeller wrote:
>  
>
>>I am aware of the Hibernate docs that the Session needs to be discarded
>>when an exception was thrown. However, I find that an overly strict
>>statement (just like "there is no such thing as a non-transactional
>>Session", their famous statement from their forums mid last year).
>>    
>>
>
>Okay, i tend to agree about it being an overly strict statement, also because 
>I've looked into SessionImpl.clear() and it does what we want :-) ... but: 
>When they've explicitly stated that a Session should not be reused in case of 
>exception, upcoming implementations of Session might break spring then. Can 
>it not?
>
>  
>
>>Session.clear should be good enough for resetting an OSIV Session after a
>>rollback. It's probably advisable to not use OSIV in single session mode at
>>all if you want to avoid side effects completely. (Closing the Session and
>>opening a new one during OSIV doesn't really add value here.)
>>    
>>
>
>It will add the value that:
>  1) the failing session is thrown away
>  2) new calls into spring-managed beans will operate fine on the new session
>
>I know, that lazy-loading of objects from dead session will fail.
>
>  
>
>>Have you considered using OpenSessionInViewFilter in "deferred close mode",
>>that is, with the "singleSession" flag turned off? In that case, each
>>transaction will use its own Hibernate Session, but all of those Sessions
>>will be kept open until view rendering has completed.
>>    
>>
>
>Yes, actually I have tried it out. But this solution does not scale very well. 
>A JDBC connection is assigned to each hibernate Session, so using deferred 
>close uses a connection for each session. Hence, one web request will quickly 
>use many connections, at the same time.
>
>Per
>  
>
Above and beyond that, deferred close has problems with the idiom which 
some people use where the view layer will load some data via one 
transaction (such as a backing form), modify, and then call down into 
another transaction to update. At this point Hibernate will complain, 
since the data from two (or more) live sessions is being mixed. Now it's 
generally not a great idea anyway to have the view layer combine 
multiple calls into transactional service methods. This defeats 
transactional integrity. There should be one encompassing service layer 
method that does all the work. However you can't get around the need to 
call down to get the form backing object sometimes.

In my opinion, either form of the Open Session in View idiom is 
problematic and should not be used in projects that get past a certain 
size or stage...

Colin