Are httpSessions thread safe?
Not sure how OT this question is. My current plan (unless this is bad for some reason, but if so, Ted H should change his example app :-) is to stash the hibernate Session for a user into his httpSession, and reuse it on each request. A Hibernate Session instance isn't threadsafe. I imagine if two really quick http requests got generated out of the same browser, all hell could break out. I guess I want to know if mortals like me need to worry about this. Does Struts (or the Servlet container FAIK) prevent this from occuring, or do I need to ensure this doesn't happen? If so, how? With a token or is there a better strategy? TIA -Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are httpSessions thread safe?
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.
If you have 1 threads playing with the same unsafe object (which you just
happened to pull out of the session) then of course you will need to
synchronise their access to it externally.
ie:
Garthop unsafeObject = (Garthop)session.getAttribute(THE_GARTHOP);
synchronized(unsafeObject)
{
garthop.nargle();
}
-Original Message-
From: Joe Hertz [mailto:[EMAIL PROTECTED]
Sent: Thursday, 18 December 2003 15:56
To: 'Struts Users Mailing List'
Subject: Are httpSessions thread safe?
Not sure how OT this question is.
My current plan (unless this is bad for some reason, but if so, Ted H
should change his example app :-) is to stash the hibernate Session for
a user into his httpSession, and reuse it on each request.
A Hibernate Session instance isn't threadsafe. I imagine if two really
quick http requests got generated out of the same browser, all hell
could break out.
I guess I want to know if mortals like me need to worry about this.
Does Struts (or the Servlet container FAIK) prevent this from occuring,
or do I need to ensure this doesn't happen? If so, how? With a token or
is there a better strategy?
TIA
-Joe
-
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]
RE: Are httpSessions thread safe?
If Hibernate sessions are not thread-safe by design, then stuffing one in a web
app session and wrapping it with your own synchronization doesn't seem like the
right approach. I've never actually used Hibernate, so I could be way off base,
but it sounds more like a job for a filter. The filter would initialize the
Hibernate session and store it as a request attribute before any other request
processing. It would then also tear down the Hibernate session at the end of the
request. Are Hibernate sessions expensive enough resources to warrant creating
only one per web app session? Another approach might be to set up Hibernate
sessions as thread-local variable...
Quoting Andrew Hill [EMAIL PROTECTED]:
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.
If you have 1 threads playing with the same unsafe object (which you just
happened to pull out of the session) then of course you will need to
synchronise their access to it externally.
ie:
Garthop unsafeObject = (Garthop)session.getAttribute(THE_GARTHOP);
synchronized(unsafeObject)
{
garthop.nargle();
}
-Original Message-
From: Joe Hertz [mailto:[EMAIL PROTECTED]
Sent: Thursday, 18 December 2003 15:56
To: 'Struts Users Mailing List'
Subject: Are httpSessions thread safe?
Not sure how OT this question is.
My current plan (unless this is bad for some reason, but if so, Ted H
should change his example app :-) is to stash the hibernate Session for
a user into his httpSession, and reuse it on each request.
A Hibernate Session instance isn't threadsafe. I imagine if two really
quick http requests got generated out of the same browser, all hell
could break out.
I guess I want to know if mortals like me need to worry about this.
Does Struts (or the Servlet container FAIK) prevent this from occuring,
or do I need to ensure this doesn't happen? If so, how? With a token or
is there a better strategy?
TIA
-Joe
--
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]
RE: Are httpSessions thread safe?
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are httpSessions thread safe?
Two threads can access and use the same object from the session at the same time. Struts does not prevent this from occurring. It is something to worry about unless you want to be woken up with bug reports in the middle of the night. :-) -Max - Original Message - From: Joe Hertz [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 11:56 PM Subject: Are httpSessions thread safe? Not sure how OT this question is. My current plan (unless this is bad for some reason, but if so, Ted H should change his example app :-) is to stash the hibernate Session for a user into his httpSession, and reuse it on each request. A Hibernate Session instance isn't threadsafe. I imagine if two really quick http requests got generated out of the same browser, all hell could break out. I guess I want to know if mortals like me need to worry about this. Does Struts (or the Servlet container FAIK) prevent this from occuring, or do I need to ensure this doesn't happen? If so, how? With a token or is there a better strategy? TIA -Joe - 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]
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/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are httpSessions thread safe?
Even though you got a few different objects with those calls, they all
represent the same conceptual session underneath. The concept of a session
would be worthless otherwise. In other words, if you stash a reference to
some object in the session, you will be able to get a reference to that same
object from any of the session objects returned by those calls (even though
the object representing the session itself may be different from call to
call).
-Max
- Original Message -
From: Kris Schneider [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 8:11 AM
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/
-
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]
Re: Are httpSessions thread safe?
The point is about synchronizing on the session object, in which case it makes
all the difference in the world that different instances are used to represent
the same conceptual session.
Quoting Max Cooper [EMAIL PROTECTED]:
Even though you got a few different objects with those calls, they all
represent the same conceptual session underneath. The concept of a
session
would be worthless otherwise. In other words, if you stash a reference to
some object in the session, you will be able to get a reference to that
same
object from any of the session objects returned by those calls (even though
the object representing the session itself may be different from call to
call).
-Max
- Original Message -
From: Kris Schneider [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 8:11 AM
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]
RE: Are httpSessions thread safe?
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/
-
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]
Re: Are httpSessions thread safe?
At 8:22 AM -0800 12/18/03, Max Cooper wrote: Even though you got a few different objects with those calls, they all represent the same conceptual session underneath. The concept of a session would be worthless otherwise. In other words, if you stash a reference to some object in the session, you will be able to get a reference to that same object from any of the session objects returned by those calls (even though the object representing the session itself may be different from call to call). Sure, but Kris is right -- that doesn't mean that you are correctly synchronizing access to the session -- object locks are based on object identity, not the conceptual identity of something they contain. Thanks to Kris for pointing that out -- I'd say that furthers the rationale for using your own objects to encapsulate the session environment in your application. If you moved my code block into a PlugIn or other expert who was responsible for instantiating and retrieving the shells, then you could just synchronize the access methods on the expert. You might still run into issues if you were running in a clustered environment -- I don't have much experience in that kind of deployment. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: Are httpSessions thread safe?
Another question along the same vein.. each httpRequest that comes into say
Tomcat is given a seperate thread to operate under correct?
-David
- Original Message -
From: Andrew Hill [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 1:09 AM
Subject: RE: Are httpSessions thread safe?
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.
If you have 1 threads playing with the same unsafe object (which you just
happened to pull out of the session) then of course you will need to
synchronise their access to it externally.
ie:
Garthop unsafeObject = (Garthop)session.getAttribute(THE_GARTHOP);
synchronized(unsafeObject)
{
garthop.nargle();
}
-Original Message-
From: Joe Hertz [mailto:[EMAIL PROTECTED]
Sent: Thursday, 18 December 2003 15:56
To: 'Struts Users Mailing List'
Subject: Are httpSessions thread safe?
Not sure how OT this question is.
My current plan (unless this is bad for some reason, but if so, Ted H
should change his example app :-) is to stash the hibernate Session for
a user into his httpSession, and reuse it on each request.
A Hibernate Session instance isn't threadsafe. I imagine if two really
quick http requests got generated out of the same browser, all hell
could break out.
I guess I want to know if mortals like me need to worry about this.
Does Struts (or the Servlet container FAIK) prevent this from occuring,
or do I need to ensure this doesn't happen? If so, how? With a token or
is there a better strategy?
TIA
-Joe
-
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]
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
Re: Are httpSessions thread safe?
Agreed. I wasn't thinking that the question was to literally synchronize on the session object itself. I see now that that may have been the original intent. Synchronizing on the session object itself seems like a really dangerous idea to me (invitation for deadlock, performance issues). And Kris's test shows it probably wouldn't do what you expect it to anyway. -Max - Original Message - From: Kris Schneider [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 8:32 AM Subject: Re: Are httpSessions thread safe? The point is about synchronizing on the session object, in which case it makes all the difference in the world that different instances are used to represent the same conceptual session. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Re: Are httpSessions thread safe?
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=149353
From: David Erickson [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List
[EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: Re: Are httpSessions thread safe?
Date: Thu, 18 Dec 2003 10:26:56 -0700
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
RE: Are httpSessions thread safe?
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
Re: Are httpSessions thread safe?
Most (all?) containers pool the request-handler threads, so it won't be creating hibernate sessions for each request. It would still be thread safe, since a single thread won't be used to process two requests simultaneously. This sounds like a good approach to me -- safe and likely to perform just fine. -Max - Original Message - From: David Erickson [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 9:26 AM 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
Re: Are httpSessions thread safe?
Well what that plugin does is IF you request a session from it, it binds a Hibernate Session to your current executing thread. thus if you are using actions, anywhere in that action and in the resulting jsp the same session is used if you requested it again. And on requests for images or whatever since its never requested it doesn't get created. If you are using a connection pool like DBCP or something it shouldnt be a problem at all. -David - Original Message - From: Joe Hertz [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 10:41 AM Subject: RE: Are httpSessions thread safe? 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
