On Sat, 18 May 2002, Galbreath, Mark wrote:
> Date: Sat, 18 May 2002 12:42:56 -0400
> From: "Galbreath, Mark" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: Small Complaint - Struts Impl.
>
> That's my feeling as well, Tim. I asked Craig about this a few weeks ago
> and based on (probably my misunderstanding of) his response, I synchronized
> all the mutators and accessors in the bean. Since it's session scoped, I
> don't think this is a performance issue, but I also think it's unnecessary.
> Especially since I have the relevant associated blocks in my Action class
> synchronized. Like you, I thought reset() for a session bean was pointless
> and though I kept the method because I was not sure if ActionServlet would
> blow up without it, I made it impotent.
>
See previous responses regarding reset(). However, a remark about the
need for synchronization ...
One of the really nice things about form beans in request scope is that
you basically don't have to worry about thread safety -- a new form bean
gets created for you on each request, and it's thrown away at the end. In
between, no thread other than the one processing this request has access
to it, so you can basically pretend (for the form bean) that threads to
not exist.
When using session scope form beans (or, more generally, any session scope
attributes), you *do* have to be concerned about the case where the same
user (therefore accessing the same session) might be accessing the same
form bean on more than one thread at the same time.
"But how can that possibly happen?" you might ask. Consider the following
three scenarios:
* You are using frames in your presentation. Most browsers
will fire off multiple simultaneous requests to fill up
the frame contents, and they will all be accessing the same
session.
* Your user submits a request that takes a long time to process,
but gets impatient -- he or she presses Stop and then submits
the page again. (Haven't *you* ever done that to a webapp that
is responding slowly? :-).
* Your user opens two windows and accesses the application from
both of them. Depending on how your browser works, the two
windows will usually be in the same session, and you will have
to deal with the possibility that he or she might access the
same form (and therefore the same session-stored form bean
instance) from both windows at the same time.
As you can see, session-based form beans can cause you some grief ...
besides the memory consumption issues, which is the primary reason that
most people try to avoid them.
On the "good news" side of the equation, though, you *still* might not
need to synchronize things. For example:
* The container is responsible for making sure that things like
session.setAttribute() work correctly, even in the face of
multithread access.
* If your underlying form bean property is a Java primitive or a
String, you generally don't need to worry about synchronizing
the setFoo() method -- the assignment statement that executes
inside the setter either runs or it doesn't.
The basic rule for synchronizing mutators is that you need to protect
blocks of code that need to run "all at once", without interference from
any other thread. For example, if you call put() on a HashMap (which is
not internally synchronized), as the method runs it will likely, at
certain points in time, have the map in an internal state that, from the
viewpoint of a different thread accessing it (such as doing a get()) is
not correct.
For that reason, having to synchronize setters usually means you need to
synchronize getters as well, but that is a different issue ...
> Mark
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
