-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: When is session-per-request preferred and when a hindrance?
PostPosted: Fri Mar 27, 2009 10:44 pm 
Regular
Regular

Joined: Wed Jan 21, 2009 8:41 pm
Posts: 54
So I''m trying to fix a problem caused by the need to use select-before-update in an application because the persistence wrapper around hibernate attempts to hide the session and transaction such that when using the session-per-request pattern every invocation of a database operation opens a new session and at the end of every database operation in a finally block closes the session. Since we used ehcache as a second level cache and eager fetching across our entire model we essentially avoid having to deal with detatched objects explicitly but we pay the price thru the need to rely on select-before-update because performant dirty checking doesn't exist. This means we are burdened with unnecessary fetches thru select-before-update than we would be had we exposed the session and transaction to the higher levels of the application and force explicit transaction boundarys. In an effort to wrap hibernate and hide it's specifics a non-web application is essentially written like it's a web application ie. session-per-request instead of session-per-conversation.

I'm looking at what would be necessary in order to reuse the Session. Obviously when you take away session-per-request you then have to expose the transaction and eventually close it and have the session closed when it's closed.

I initially thought about replacing the existing calls of openSession with getCurrentSession and using thread session local but that doesn't fit in with the existing code as well because with that approach you are restricted to calling beingTransaction on the session immediately before you can even call createCriteria so you have to have a transaction for all your existing wrapped query methods. This is something that wasn't explicitly required when calling openSession as you don't use ThreadLocalSessionContext with that approach and so you don't have the restrictions that come with that.

My goal is to avoid the need to use select-before-update by ensuring that the session/transaction is longer lived for the entire request where request is the higher level object that I'm processing rather than a single database operation that currently wraps hibernate such as a getListBy or save or update method.

I'm ok with still relying on eager fetching as that eliminates the need to deal with detatched objects.

Is there anybody who subscribes to what I described earlier and who has previously converted an application from session-per-request to session-per-conversation?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.