I guess creating Hibernate Sessions and Destroying them on every request isn't as bad as I imagine it is?
I figured creating the session when the user showed up, destroying it when his httpSession expired, and reconnecting/disconnecting on each request was strictly better. I guess doing this isn't quite worth the effort? No one else seems to mind :) -Joe > -----Original Message----- > From: David Erickson [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 18, 2003 12:27 PM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Are httpSessions thread safe? > > > That second one actually works great, 43.html. Since each > request is running in its own thread it has the possiblity to > create a new hibernate session for every request, but it only > creates it if you call the getSession method on the filter. > And at the end of the request that session is destroyed. -David > > ----- Original Message ----- > From: "Joe Hertz" <[EMAIL PROTECTED]> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > Sent: Thursday, December 18, 2003 10:20 AM > Subject: RE: Are httpSessions thread safe? > > > > I saw these. I just had this grand idea of minimizing the Hibernate > > connections by doing what Ted did in his example -- not actually > > discarding a user's Hibernate Session until his httpSession expired. > > > > I've never messed with ThreadLocals before but I suspect that the > > attempt to put a ThreadLocal into a httpSession I suspect would be > > funny to watch. > > > > > > > > > -----Original Message----- > > > From: Kris Schneider [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 18, 2003 11:45 AM > > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > > Subject: RE: Are httpSessions thread safe? > > > > > > > > > Poked aroung on the Hibernate site for a few minutes and found > > > these: > > > > > > http://www.hibernate.org/42.html http://www.hibernate.org/43.html > > > > > > Quoting Joe Hertz <[EMAIL PROTECTED]>: > > > > > > > Yuck. And may I say, "Yuck", again? > > > > > > > > It's not the Session object per se, as much as it is the > > > > particular attribute I want to store there. > > > > > > > > It does strike me that the storage of a Hibernate > Session in the > > > > httpSession is a fairly common thing, so I doubt this > bites people > > > > very often. It does seem to have the potential to do so. > > > > > > > > In the "real world" why is this not too big of a deal? Or > > > should it be > > > > considered one? > > > > > > > > I suppose that unless you've got time consuming requests, > > > or the user > > > > hits some button on the browser twice in rapid succession, it's > > > > probably okay. A token could effectively prevent this type of > > > > condition I suppose. > > > > > > > > -J > > > > > > > > > -----Original Message----- > > > > > From: Kris Schneider [mailto:[EMAIL PROTECTED] > > > > > Sent: Thursday, December 18, 2003 11:12 AM > > > > > To: Struts Users Mailing List > > > > > Subject: RE: Are httpSessions thread safe? > > > > > > > > > > > > > > > Synchronizing on the session object may cause you all > sorts of > > > > > grief...or it may not. It all depends on your container. The > > > > > spec makes no guarantees about the identity of the object > > > > > returned by methods like PageContext.getSession or > > > > > HttpServletRequest.getSession. For example, here's a test JSP: > > > > > > > > > > <%@ page contentType="text/plain" %> > > > > > <% > > > > > out.println("session: " + session); > > > > > out.println("pageContext.getSession: " + > > > pageContext.getSession()); > > > > > out.println("request.getSession: " + > > > request.getSession(false)); > > > > > out.println("request.getSession: " + > > > request.getSession(false)); > > > > > %> > > > > > > > > > > Here's the output from TC 4.1.24: > > > > > > > > > > session: > > > > > [EMAIL PROTECTED] > > > > > pageContext.getSession: > > > > > [EMAIL PROTECTED] > > > > > request.getSession: > > > > > [EMAIL PROTECTED] > > > > > request.getSession: > > > > > [EMAIL PROTECTED] > > > > > > > > > > And that's just within the same thread! I'm pretty sure TC > > > > > 4.1.29 does return the same instance, but just > remember it's not > > > > > guaranteed. > > > > > > > > > > Quoting Joe Germuska <[EMAIL PROTECTED]>: > > > > > > > > > > > At 4:09 PM +0800 12/18/03, Andrew Hill wrote: > > > > > > >The sessions essentially just a sort of Map. Access to > > > it may be > > > > > > threadsafe, > > > > > > >but the stuff thats in it is another matter entirely. > > > > > > >Multiple requests associated with the same session will > > > > > > >execute simultaneously. > > > > > > > > > > > > There's nothing in the specs that guarantee threadsafe > > > access to > > > > > > session attributes. > > > > > > > > > > > > A pattern I've become quite fond of is to create a > > > single object > > > > > > (we call it a "shell", analogous to an operating > system shell) > > > > > > which encapsulates everything you want in session > context for > > > > > > a > > > > > given user; > > > > > > then put just this object into session scope, and use > > > methods on > > > > > > it > > > > > > to do everything else. This helps you apply > > > synchronization where > > > > > > appropriate. There's still a risk of a race condition > > > > > involving the > > > > > > initial creation of the shell (assuming you do > something like > > > > > > check the session to see if there's a value under > the key you > > > use for the > > > > > > shell) -- you can put that in a block synchronized on > > > the session > > > > > > object: > > > > > > > > > > > > MyAppShell shell = null; > > > > > > synchronized (session) > > > > > > { > > > > > > shell = (MyAppShell) session.getAttribute(SHELL_KEY); > > > > > > if (shell == null) > > > > > > { > > > > > > shell = new MyAppShell (); > > > > > > session.setAttribute(SHELL_KEY, shell); > > > > > > } > > > > > > } > > > > > > > > > > > > If the "shell" concept seems like high overhead to you, you > > > > > can still > > > > > > synchronize accesses on the session object along those > > > > > lines; you may > > > > > > just have more trouble keeping track of all the places > > > it needs to > > > > > > happen. > > > > > > > > > > > > Joe > > > > > > > > > > > > -- > > > > > > Joe Germuska > > > > > > [EMAIL PROTECTED] > > > > > > http://blog.germuska.com > > > > > > "We want beef in dessert if we can get it there." > > > > > > -- Betty Hogan, Director of New Product Development, > > > National > > > > > > Cattlemen's Beef Association > > > > > > > > > > -- > > > > > Kris Schneider <mailto:[EMAIL PROTECTED]> > > > > > D.O.Tech <http://www.dotech.com/> > > > > > > -- > > > Kris Schneider <mailto:[EMAIL PROTECTED]> > > > D.O.Tech <http://www.dotech.com/> > > > > > > > -------------------------------------------------------------------- > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
