Yes access must be serialized or it will not work.
On 8/9/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > That's why I'd suggest synchronizing so that all of a given > session's requests get serialized. Otherwise, I dunno how to take a crack at > this one sort of manually serializing each and every interaction with the > Hibernate session which strikes me as rather error prone. > > Dunno; maybe somebody else has a better idea. > > --- Pat > > > -----Original Message----- > > From: Pablo Ruggia [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 08, 2005 3:36 PM > > To: Tapestry users > > Subject: Re: Hibernate Long term session > > > > Having many sessions for one user won't work well with long session > > pattern. > > What session you connect and disconnect ?? You will be having > > LazyInitializationExceptions everewhere. > > > > On 8/8/05, Lukáš Kolísko <[EMAIL PROTECTED]> wrote: > > > > > > Your solution is thread safe. I was thinking about ThreadLocal > > > variable where you store session. If I understand the process all > > > right it goes this way: > > > > > > public static void attachSession(HttpSession hs) { > > > Session s = (Session) > > > MyServlet.getCurrentSession().getAttribute( > > > SESSION_KEY); > > > if (s == null) { > > > s = createNewSession(); > > > > > > MyServlet.getCurrentSession().setAttribute(SESSION_KEY, s); > > > } > > > if (!s.isConnected()) > > > s.reconnect(); > > > > > > And here a copy of hibernate session is created for this thread. If > > > other thread enters this method, another copy of session is created > > > and these two sessions can be in different states. > > > > > > fThreadSession.set(s); > > > > > > } > > > > > > So each thread is working with his copy of the session assigned to > > > user session. And these session can have different internal states. > > > > > > This should be true if I understand this text from Java documentation: > > > > > > Threadlocal > > > > > > This class provides thread-local variables. These variables differ > > > from their normal counterparts in that each thread that accesses one > > > (via its get or set method) has its own, independently initialized > > > copy of the variable. > > > > > > Lucky:o) > > > > > > --------------------------------------------------------------------- > > > 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] > >
