You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Noah Levitt <nl...@columbia.edu> on 2002/06/13 01:57:39 UTC
thread safety
Hello struts users,
The issue of thread safety bugs me. It seems as though it is
standard practice to write servlets thread-*unsafely*. The
odds of it ever being a problem are slim, but still.
It seems to me that form bean setters (and probably getters)
should be synchronized. I found the following two quotes
from Craig McClanahan. To me, they seem contradictory.
However, even if we use the "that's going to be real
unusual" standard, shouldn't we synchronize setters, since,
in theory, it's the only thread-safe thing to do?
http://archive.covalent.net/jakarta/struts-dev/2000/06/0117.xml
Craig:
"For the form beans, you are creating them in a particular
user's session. If the user does two submits to the same
form at the same time you might have overlapping setXxx
method calls going on, but that's going to be real
unusual."
http://archive.covalent.net/jakarta/struts-user/2001/03/0013.xml
Craig:
"It is surprisingly easy to have multiple requests active
at the same time for the same session."
Noah
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thread safety
Posted by Noah Levitt <nl...@columbia.edu>.
On Thu, Jun 13, 2002 at 09:07:58PM -0700, Craig R. McClanahan wrote:
>
> Not always. Example -- let's say you have a String property (very common
> in a form bean), so you have a setter like:
>
> private String foo = null;
>
> public String getFoo() {
> return (this.foo);
> }
>
> public void setFoo(String foo) {
> this.foo = foo;
> }
>
> These methods do not need to be synchronized, because the assignments are
> atomic.
Ah, indeed you are right. I was under the impression that
their atomicity was platform-dependent, but I see from the
java language spec that I was mistaken.
>
> > Would you also agree that every call to
> > session.setAttribute() and session.getAttribute() needs to
> > be synchronized?
>
> Absolutely not. The container takes care of ensuring that this call is
> thread safe on its internal implementation.
>
That's a relief. And I see that access to the attributes is
synchronized in org.apache.catalina.session.StandardSession.
I didn't find any reassuring words in the servlet api,
though. Is the requirement stated somewhere?
Thanks for your help.
Noah
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thread safety
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 13 Jun 2002, Noah Levitt wrote:
> Date: Thu, 13 Jun 2002 14:45:35 -0400
> From: Noah Levitt <nl...@columbia.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: thread safety
>
> Hello,
>
> Your suggestion is duly noted, and would probably be good
> advice for many web apps. But keeping form beans in session
> scope can be very handy at times, as has been pointed out in
> other posts. Sessions are one of the main advantages of
> servlets, after all.
>
Everything in life is a tradeoff ... session-scoped form beans survive in
between requests, but you have to worry about thread safety. Request
scoped attributes don't survive, but thread safety is assured. Pick the
approach that best meets your particular requirements, and deal with the
downside appropriately.
> So, you concede that using form beans the way they are
> commonly used, in session scope with setters and getters
> unsynchronized, is not thread-safe?
>
Not always. Example -- let's say you have a String property (very common
in a form bean), so you have a setter like:
private String foo = null;
public String getFoo() {
return (this.foo);
}
public void setFoo(String foo) {
this.foo = foo;
}
These methods do not need to be synchronized, because the assignments are
atomic.
The times you need to synchronize property setters is when they modify
some complex data structure (like a HashMap) that is not already ensuring
thread safety (the way Hashtable does).
NOTE 1: If you have to synchronize the setter, you probably also have to
synchronize the getter so that it doesn't try to run when the setter is in
the middle of modifying the data structure.
NOTE 2: It's better to synchronize on just the object being updated,
rather than adding the "synchronized" modifier to the method itself. For
example, this:
private HashMap foos = new HashMap();
public synchronized Foo getFoo(String key) {
return ((Foo) foos.get(key));
}
public synchronized void addFoo(Foo foo) {
foos.put(foo.getKey(), foo);
}
is essentially equivalent to this:
private HashMap foos = new HashMap();
public Foo getFoo(String key) {
synchronized (this) {
return ((Foo) foos.get(key));
}
}
public void addFoo(Foo foo) {
synchronized (this) {
foos.put(foo.getKey(), foo);
}
}
which blocks other threads accessing *any* synchronized method on this
bean, even if they aren't touching the "foos" instance variable. A better
approach:
private HashMap foos = new HashMap();
public Foo getFoo(String key) {
synchronized (foos) {
return ((Foo) foos.get(key));
}
}
public void addFoo(Foo foo) {
synchronized (foos) {
foos.put(foo.getKey(), foo);
}
}
blocks only getFoo() and addFoo() calls from interfering with each other.
> Would you also agree that every call to
> session.setAttribute() and session.getAttribute() needs to
> be synchronized?
Absolutely not. The container takes care of ensuring that this call is
thread safe on its internal implementation.
>
> Noah
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: thread safety
Posted by Andrew Hill <an...@gridnode.com>.
The hidden fields idea while technically possible becomes somewhat
unmanageable (ie: hard to maintain and prohibitively time consuming to
implement) when you have a lot of fields and where you need to do
comparisons on the new and old values when the request is submitted.
-----Original Message-----
From: Noah Levitt [mailto:nlevitt@columbia.edu]
Sent: Friday, June 14, 2002 02:46
To: Struts Users Mailing List
Subject: Re: thread safety
Hello,
Your suggestion is duly noted, and would probably be good
advice for many web apps. But keeping form beans in session
scope can be very handy at times, as has been pointed out in
other posts. Sessions are one of the main advantages of
servlets, after all.
So, you concede that using form beans the way they are
commonly used, in session scope with setters and getters
unsynchronized, is not thread-safe?
Would you also agree that every call to
session.setAttribute() and session.getAttribute() needs to
be synchronized?
Noah
On Wed, Jun 12, 2002 at 11:17:03PM -0700, Craig R. McClanahan wrote:
>
>
> The simplest way to avoid this whole set of problems is to use request
> scope for your form beans. Then, the container guarantees that only one
> thread can access these beans, so you don't need to be concerned at all
> about thread safety in them.
>
> Following this advice will also be beneficial, in general, to the
> scalability of your application -- because the server will not need to
> store the form beans in memory "in between" requests.
>
> Craig
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thread safety
Posted by Noah Levitt <nl...@columbia.edu>.
Hello,
Your suggestion is duly noted, and would probably be good
advice for many web apps. But keeping form beans in session
scope can be very handy at times, as has been pointed out in
other posts. Sessions are one of the main advantages of
servlets, after all.
So, you concede that using form beans the way they are
commonly used, in session scope with setters and getters
unsynchronized, is not thread-safe?
Would you also agree that every call to
session.setAttribute() and session.getAttribute() needs to
be synchronized?
Noah
On Wed, Jun 12, 2002 at 11:17:03PM -0700, Craig R. McClanahan wrote:
>
>
> The simplest way to avoid this whole set of problems is to use request
> scope for your form beans. Then, the container guarantees that only one
> thread can access these beans, so you don't need to be concerned at all
> about thread safety in them.
>
> Following this advice will also be beneficial, in general, to the
> scalability of your application -- because the server will not need to
> store the form beans in memory "in between" requests.
>
> Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: thread safety
Posted by Andrew Hill <an...@gridnode.com>.
Using the request scope can be troublesome to say the least.
In my app I obtain an object (via an abstraction layer) from the j2ee side
and I need to present certain properties of it in the form (via the action
form), and then when the request comes back in from this form I need to
compare various fields to see if they have changed and only then do certain
things.
While I could look up the object again, this seems most inefficient.
Also, how do we deal with the situation where we need to build up
information over a series of requests before we can actually save it or do
something with it (ie: wizards etc...)
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Thursday, June 13, 2002 14:17
To: Struts Users Mailing List
Subject: Re: thread safety
On Wed, 12 Jun 2002, Noah Levitt wrote:
> Date: Wed, 12 Jun 2002 19:57:39 -0400
> From: Noah Levitt <nl...@columbia.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: thread safety
>
> Hello struts users,
>
> The issue of thread safety bugs me. It seems as though it is
> standard practice to write servlets thread-*unsafely*. The
> odds of it ever being a problem are slim, but still.
>
> It seems to me that form bean setters (and probably getters)
> should be synchronized. I found the following two quotes
> from Craig McClanahan. To me, they seem contradictory.
> However, even if we use the "that's going to be real
> unusual" standard, shouldn't we synchronize setters, since,
> in theory, it's the only thread-safe thing to do?
>
> http://archive.covalent.net/jakarta/struts-dev/2000/06/0117.xml
>
> Craig:
> "For the form beans, you are creating them in a particular
> user's session. If the user does two submits to the same
> form at the same time you might have overlapping setXxx
> method calls going on, but that's going to be real
> unusual."
>
> http://archive.covalent.net/jakarta/struts-user/2001/03/0013.xml
>
> Craig:
> "It is surprisingly easy to have multiple requests active
> at the same time for the same session."
>
The simplest way to avoid this whole set of problems is to use request
scope for your form beans. Then, the container guarantees that only one
thread can access these beans, so you don't need to be concerned at all
about thread safety in them.
Following this advice will also be beneficial, in general, to the
scalability of your application -- because the server will not need to
store the form beans in memory "in between" requests.
Craig
>
> Noah
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thread safety
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 12 Jun 2002, Noah Levitt wrote:
> Date: Wed, 12 Jun 2002 19:57:39 -0400
> From: Noah Levitt <nl...@columbia.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: thread safety
>
> Hello struts users,
>
> The issue of thread safety bugs me. It seems as though it is
> standard practice to write servlets thread-*unsafely*. The
> odds of it ever being a problem are slim, but still.
>
> It seems to me that form bean setters (and probably getters)
> should be synchronized. I found the following two quotes
> from Craig McClanahan. To me, they seem contradictory.
> However, even if we use the "that's going to be real
> unusual" standard, shouldn't we synchronize setters, since,
> in theory, it's the only thread-safe thing to do?
>
> http://archive.covalent.net/jakarta/struts-dev/2000/06/0117.xml
>
> Craig:
> "For the form beans, you are creating them in a particular
> user's session. If the user does two submits to the same
> form at the same time you might have overlapping setXxx
> method calls going on, but that's going to be real
> unusual."
>
> http://archive.covalent.net/jakarta/struts-user/2001/03/0013.xml
>
> Craig:
> "It is surprisingly easy to have multiple requests active
> at the same time for the same session."
>
The simplest way to avoid this whole set of problems is to use request
scope for your form beans. Then, the container guarantees that only one
thread can access these beans, so you don't need to be concerned at all
about thread safety in them.
Following this advice will also be beneficial, in general, to the
scalability of your application -- because the server will not need to
store the form beans in memory "in between" requests.
Craig
>
> Noah
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>