RE: why only one instance of Action class (Action class thread sa fety)

[Margaritis Jason Contractor USTC <ja...@hq.transcom.mil>]

Kinda new to struts,
but wouldn't it be trivial to implement this on top of the current framework
by having your Action instantiate a new Object (could be an Action) and go
from
there?  But i don't really see how instance variables are going to shorten
parameter lists.


-----Original Message-----
From: Brendan.Johnston@WellsFargo.COM
[mailto:Brendan.Johnston@WellsFargo.COM]
Sent: Tuesday, May 06, 2003 1:35 PM
To: struts-dev@jakarta.apache.org
Subject: RE: why only one instance of Action class (Action class thread
sa fety)


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.

Brendan



-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
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
safety)




On Mon, 5 May 2003, Bradley Hill wrote:

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

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

Re: RE: why only one instance of Action class (Action class thread safety)

[Kent Sølvsten Rasmussen <ke...@aarhusmail.dk>]

Instance variables (or properties) would be able to shorten parameterlists.

If Action had Request scope (implemented by instantiating new objects, or pooling), it would be possible to let Request and Response be instancevariables or properties on the Action object (populated by the framework). Thus they would be unneccessary in the execute method. This could be a way (but possibly not the best!) to decrease the dependency of the Servlet API. And maybe there could be a DefaultAction unaware of the Servlet API (easy to test), and a WebAction with Request/Response properties, and maybe somewhere down the road a SwingAction?

This is, of course, very difficult to implement without breaking backwards compatibility.


Margaritis Jason Contractor USTC <ja...@hq.transcom.mil> wrote:
> Kinda new to struts,
> but wouldn't it be trivial to implement this on top of the
> current framework
> by having your Action instantiate a new Object (could be an
> Action) and go
> from
> there?  But i don't really see how instance variables are
> going to shorten
> parameter lists.
> 
> 
> -----Original Message-----
> From: Brendan.Johnston@WellsFargo.COM
> [mailto:Brendan.Johnston@WellsFargo.COM]
> Sent: Tuesday, May 06, 2003 1:35 PM
> To: struts-dev@jakarta.apache.org
> Subject: RE: why only one instance of Action class (Action
> class thread
> sa fety)
> 
> 
> 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.
> 
> Brendan
> 
> 
> 
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> 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
> safety)
> 
> 
> 
> 
> On Mon, 5 May 2003, Bradley Hill wrote:
> 
> > Date: Mon, 5 May 2003 10:59:26 -0600 (MDT)
> > From: Bradley Hill <al...@gwl.com>
> > Reply-To: Struts Developers List
> <st...@jakarta.apache.org>,
> >      Bradley Hill <al...@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
> 
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org


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