struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan.Johns...@WellsFargo.COM
Subject RE: why only one instance of Action class (Action class thread sa fety)
Date Tue, 06 May 2003 18:35:06 GMT
I am still thinking about how to hack the Wiki but...

The advantages to the "action instance per request" approach are:

* The current approach means that users must be specifically cautioned about
the issues for *actions*.
* Instance variables can be used by both the framework and users to shorten
parameter lists etc.

The disadvantage to this new alternative approach is that it is different
from the current struts model.

If a mechanism can be invented so that new isolated actions are clearly
distinguished from singleton actions to provide backward compatablity, for
humans and source, then the change can be made.

I personally like instance variables, and I like not having to worry about
shared variables when I don't have too.


-----Original Message-----
From: Craig R. McClanahan []
Sent: Monday, May 05, 2003 12:34 PM
To: Struts Developers List; Bradley Hill
Subject: Re: why only one instance of Action class (Action class thread

On Mon, 5 May 2003, Bradley Hill wrote:

> Date: Mon, 5 May 2003 10:59:26 -0600 (MDT)
> From: Bradley Hill <>
> Reply-To: Struts Developers List <>,
>      Bradley Hill <>
> To:
> Subject: Re: why only one instance of Action class (Action class thread
>     safety)
> Indeed, the multi-threaded use of Actions is much like the Servlet API,
> but most Struts users (not developers) at this point are probably more
> familiar with the JSP APIs than with working directly with "pure"
> Servlet apps.

None of this is relevant for 1.x anyway, but I would counter this with the
observation that people who don't understand the fundamentals of the APIs
they are using are going to run into trouble no matter how "simple" we try
to make them.

Case in point - sessions can be accessed from multiple threads
simultaneously, and it's ridiculously easy to cause this to happen.  It
doesn't matter whether you are used to the JSP or the Servlet APIs for
accessing session attributes -- if you don't understand this, your app is
going to fail in mysterious ways.

There are lots more similar issues that servlet and JSP inherit simply
because they run on top of a stateless protocol (HTTP).  You cannot write
robust web-based applications without understanding them -- papering over
the problems with simpler apis makes webapp development more approachable,
but it cannot hide the fundamental ugliness of HTTP.

> Why not use the lifecycle model of a JSP tag for Actions?  Pool them for
> performance (if it's even worth the trouble), include a reset/cleanup
method to
> be called by the framework, and guarantee single-threaded access within
> scope of a request.

JSP 1.2 taught the world that the lifecycle model of custom tag instances
was horribly hard to use, and even more difficult to program for than the
thread-safe single instance model.

It is so bad that, in JSP 2.0, a new API (SimpleTag) was introduced that
(among other things) dispenses with all the pooling complexity and just
creates instances every time.

> It would be an equally familiar and easy to explain by analogy model for
> most users and avoid the issues surrounding thread safety which, if in
> practice are not actually so complicated, many find intimidating and
> unintuitive.

Strong advice from having lived through tags and pooling -- don't go there

> Brad Hill


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message