-->
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.  [ 5 posts ] 
Author Message
 Post subject: When to close a session...
PostPosted: Thu Apr 22, 2004 5:51 pm 
Regular
Regular

Joined: Sat Oct 18, 2003 11:53 am
Posts: 55
I have an issue that I can't think of a quick/easy solution for, when to close my session. If I use the ThreadLocal pattern, to close the session, I still have to explicitly call closeSession() correct? How can I close the session when the ThreadLocal dies? If I wrap the session and put close in the finalize, I am at the whim of the garbage collection, if I call closeSession at the end of a method that is inefficient since I might call X methods for every web transaction. I can't use the Filter pattern since I am in the middle of a refactoring...

Anyone got somethin?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 22, 2004 7:04 pm 
Expert
Expert

Joined: Thu Jan 08, 2004 6:17 pm
Posts: 278
You close the session just before your web transaction completes (i.e. if you're in a servlet, you close it before you send the response). It has nothing to do with the lifetime of the thread, only with the lifetime of the request handler.

In other words: when did you OPEN the session? Whenever the thing you were doing when you OPENED the session completes, that's when you should CLOSE the session. :-)

Cheers!
Rob


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 22, 2004 7:46 pm 
Regular
Regular

Joined: Sat Oct 18, 2003 11:53 am
Posts: 55
I can see your point to a degree, but I would like to write my Dao's / Store's as isolated objects since sometimes they are used in a command line app, othertimes in a Web app. Sometimes the JSP's call the Dao's directly (ugly, I know) and that stuff is being refactored out, but there is nothing I can do about it now.

I supposed there is nothing I can do until the refactoring is done. Thanks.

Matt Dowell


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 22, 2004 8:14 pm 
Expert
Expert

Joined: Thu Jan 08, 2004 6:17 pm
Posts: 278
I don't understand the problem. You write the DAOs as objects that use the ThreadLocal Session. Then whoever is calling the DAOs is responsible for setting up and closing the Session for that thread.

In other words, you have:
Code:
SomeCallerMethod (servlet method, standalone app method, whatever)
    CreateThreadLocalSession
    CallDao1
        GetThreadLocalSession
        DoHibernateStuff
    CallDao2
        GetTLS
        DoHibernateStuff
     Flush
     CloseSession
End SomeCallerMethod

So the DAOs have no idea who is calling them. All they know is they can get a ThreadLocalSession to do their job with.

I know this works since we have exactly the same pattern. We have DAOs that are used either in our beans or in our unit tests (i.e. our stand-alone JUnit classes). They work just fine in either place, getting their TLS from our singleton Persistence Hibernate-wrapper class.

Cheers
Rob


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 22, 2004 8:15 pm 
Expert
Expert

Joined: Thu Jan 08, 2004 6:17 pm
Posts: 278
Oh, I see. Ya, if the JSPs call the DAOs directly, then that's pretty fubar. You could put session closes into your JSPs, but that's ugly.

Good thing you're refactoring :-)
Cheers!
Rob


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

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.