struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: why only one instance of Action class (Action class thread safety)
Date Mon, 05 May 2003 19:33:36 GMT


On Mon, 5 May 2003, Bradley Hill wrote:

> Date: Mon, 5 May 2003 10:59:26 -0600 (MDT)
> From: Bradley Hill <alpn@gwl.com>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>,
>      Bradley Hill <alpn@gwl.com>
> To: struts-dev@jakarta.apache.org
> 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 the
> 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
> bradley.hill@gwl.com
>

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message