Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
From: "David Graham" <dgraham1980@hotmail.com>
To: struts-dev@jakarta.apache.org
Bcc: 
Subject: RE: why only one instance of Action class (Action class thread sa
 fety)
Date: Tue, 06 May 2003 18:40:14 -0600
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law15-F400UX2REZTBq00000fd3@hotmail.com>

Using a Singleton is faster than creating a new object for each request, 
especially for high traffic applications.  If you need instance variables 
then you likely have too much logic in your action that should go into a 
separate layer.

There is nothing preventing you from using instance variables in actions but 
you must do it in a thread safe manner.  The easiest solution is to just not 
use them.

It's trivial to override RequestProcessor.processActionCreate to return a 
new Action for each request so Struts doesn't even have to support this by 
default.

David


>From: Brendan.Johnston@WellsFargo.COM
>Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
>To: struts-dev@jakarta.apache.org
>Subject: RE: why only one instance of Action class (Action class thread sa 
>fety)
>Date: Tue, 6 May 2003 17:08:50 -0700
>
>The struts designers clearly do not agree that actions
>should be single use.  They are not single use now.
>
>This shows that Struts designers have different tastes to me.
>I have yet to see one advantage of singleton actions.
>
>What advantage of singletons am I not getting?
>
>I have responded to the other comments.
>But this seems like a useless distraction
>if Singleton actions have zero advantages.
>
>All parts of a web application do not have to be reentrant.
>ActionForms do not have to be reentrant.
>In general re-entrant code is very hard to test and therefore likely to be
>buggy.
>I would suggest that all part of a web application
>that are written by applications prgrammers should not be re-entrant.
>
>To avoid the problem Craig mentioned with session,
>one solution is to insert a standard object whenever you create a new
>session,
>and in your request processor / wib action server / some filter, 
>synchronize
>on that object.  I think I might implement that.
>
>All the actions I have written have no instance variables.
>That's because instance variables would be useless/dangerous
>because they are shared by all requests.
>
>However OO provides instance variables and they are useful in my designs.
>When I look at actions, I see functional decomposition,
>not object oriented designs.
>
>Instantiating another object to get around this sometimes does not
>work well with subclassed actions.
>
>For an example of a shorter parameter list, see the wiki posted by Ted.
>http://nagoya.apache.org/wiki/apachewiki.cgi?WhyOnlyOneInstanceOfActionClass
>
>Based on road map I don't agree/understand why this is a struts 2.0 issue.
>There is no need to break backward compatability.
>
>Brendan
>
>
>-----Original Message-----
>From: Miller, Jason [mailto:jmiller@ostglobal.com]
>Sent: Tuesday, May 06, 2003 1:37 PM
>To: 'Struts Developers List'
>Subject: RE: why only one instance of Action class (Action class thread
>sa fety)
>
>
>I'll throw in one thought, as well.
>
>Having multiple instances of Actions doesn't really allow much anyway, 
>since
>ALL parts of a web app have to be reentrant.  By shifting the thread safety
>issues down one level, I don't see much being gained.  Particularly in 
>light
>of the fact that Actions should be fairly lightweight, anyway.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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