struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbert Hirneisen" <no...@s2you.de>
Subject AW: AW: AW: Struts 1 and thread safety
Date Sun, 19 Sep 2010 07:41:58 GMT
Thanks to Dave and Chris.

Now the base class is storing the projectId in the session.
Is it correct to assume that a single request is handled within one thread so
that there are no thread-safety issues within an action method to consider ?

Thanks,
Norbert

> -----Ursprüngliche Nachricht-----
> Von: Chris Mawata [mailto:chris_mawata_struts@mathcove.net] 
> Gesendet: Sonntag, 19. September 2010 01:20
> An: Struts Users Mailing List
> Betreff: Re: AW: AW: Struts 1 and thread safety
> 
> 
>   On 9/18/2010 8:36 AM, Norbert Hirneisen wrote:
> > Just another question regarding this context:
> >
> > the original code has been written by a colleague.
> > Now I´m intrigued if setting the execute-Method in the base 
> class within a
> > synchronized block makes sense ?!
> > As far as I´m understanding the action classes behave like 
> servlets and multiple
> > request can be served parallel by using multi-threading.
> > So synchronzing the execute-Methode would slow down the performance
> > significantly ??! Is my understanding correct ?
> >
> > Thanks,
> > Norbert
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Dave Newton [mailto:davelnewton@gmail.com]
> > Gesendet: Samstag, 18. September 2010 14:07
> > An: Struts Users Mailing List; nobbi@s2you.de
> > Betreff: Re: AW: Struts 1 and thread safety
> >
> >
> > No, I meant actual ThreadLocals, but what you're saying 
> would work too.
> >
> > The best way to go about doing it depends on what's being 
> done in the
> > subclasses.
> >
> > Dave
> >
> >
> > On Sat, Sep 18, 2010 at 7:53 AM, Norbert 
> Hirneisen<nobbi@s2you.de>  wrote:
> >
> >
> > Thanks, Dave.
> >
> > Using the data local means to call
> >
> > long projectId = Project.getIdFromRequest(request);
> >
> > in every subclass because there is no thread-safe way to 
> use a class field in
> > the super-class ?
> >
> > Would it be thread-safe to use a local variable in the 
> super-class and store the
> > data in the session ?
> > Is that what you mean with "passing the data around" ?
> >
> > Thanks in advance,
> > Norbert
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Dave Newton [mailto:davelnewton@gmail.com]
> > Gesendet: Samstag, 18. September 2010 13:47
> > An: nobbi@s2you.de; Struts Users Mailing List
> > Betreff: Re: AW: Struts 1 and thread safety
> >
> >
> >
> >
> > No, it's not thread safe. Actions should be treated like 
> servlets in this
> > regard, and designed better.
> >
> > Consider either passing the required data around, or using 
> thread locals.
> >
> > Dave
> >
> > On Sep 18, 2010 6:42 AM, "Norbert Hirneisen"<nobbi@s2you.de>  wrote:
> >> Nobody here who can help ?
> >>
> >>> -----Ursprüngliche Nachricht-----
> >>> Von: Norbert Hirneisen [mailto:nobbi@s2you.de]
> >>> Gesendet: Freitag, 17. September 2010 11:01
> >>> An: user@struts.apache.org
> >>> Betreff: Struts 1 and thread safety
> >>>
> >>>
> >>> Hello,
> >>>
> >>> I have al large Struts 1 application with a modified
> >>> DispatchAction class. Most
> >>> action classes are derivatives from this class.
> >>> In the webapp I have several projects defined. The project
> >>> can be determined by
> >>> analysing the URL.
> >>> This is done in the central DispatchAction-class by using
> >>> class fields declared
> >>> as volatile. The execute-Method is declared as synchronized.
> >>> After reading a lot about thread safety now I´m not sure if
> >>> this approach is
> >>> thread safe on a request level.
> >>> Abbreviated example:
> >>>
> >>> public abstract class DispatchAction extends Action {
> >>> ....
> >>> protected volatile long projectId = -1;
> >>> ....
> >>>
> >>> @Override
> >>> synchronized public ActionForward execute(
> >>> ActionMapping mapping,
> >>> ActionForm form,
> >>> HttpServletRequest request,
> >>> HttpServletResponse response)
> >>> throws Exception {
> >>> ...
> >>> long projectId = Project.getIdFromRequest(request);
> >>> ...
> >>> return forward;
> >>> }
> >>>
> >>> When I access projectId from a derived class is this thread
> >>> safe or have I to
> >>> implement in the doExecute-Method of each derived action
> >>> class ? This would be
> >>> thread safe but comes with a lot of redundant code.
> >>>
> >>> Any help would be helpful.
> >>>
> >>> Best regards,
> >>> Norbert
> >>>
> >>>
> >>>
> >>> Norbert Hirneisen
> >>>
> >>> science4you Online-Monitoring
> >>> http://www.science4you.org
> >>> email: nobbi@s2you.de
> >>>
> >>> Die Falternacht: www.falternacht.de
> >>> Werden Sie Falterzähler: www.falterfunde.de
> >>> Wanderfalter: www.science4you.org/platform/monitoring/index.do
> >>> Tagfalter-Monitoring Deutschland:
> >>> www.science4you.org/platform/tmd/tmd-top/index.do
> >>> Infos über geschützte Arten ? http://www.wisia.de
> >>>
> >>> Norbert Hirneisen
> >>> Science&  Communications
> >>>
> >>> von-Müllenark-Str. 19
> >>> 53179 Bonn
> >>> Tel. 0228/6194930
> >>> Ust.ID-Nr. DE237150377
> >>>
> >>> Der Inhalt dieser Mitteilung ist nur für obigen Adressaten
> >>> bestimmt und streng
> >>> vertraulich. Eine Weitergabe oder Vervielfältigung durch
> >>> andere als den
> >>> Adressaten ist verboten! Sollten Sie diese Nachricht
> >>> irrtümlich erhalten haben,
> >>> ersuchen wir Sie um sofortige Verständigung und darum,
> >>> sämtliche Dateien von
> >>> Ihrem Computer zu löschen. Unsere E-Mail sind geprüft,
> >>> erfolgen jedoch ohne
> >>> Gewähr.
> >>>
> >>> The information contained in this message is intended only
> >>> for the adressee. It
> >>> is strictly confidential. Any distribution, copying or
> >>> disclosure by anyone but
> >>> the adressee is prohibited. In case you have received this
> >>> message in error,
> >>> please notify us immediately and delete it form your system.
> >>> Any liability for
> >>> information send via email of us is excluded.
> >>>
> >>>
> >>> 
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: user-help@struts.apache.org
> >>>
> >>
> >> 
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >
> >
> >
> >
> >
> Synchronizing will cost you time when you have many clients. If there 
> are other locks in the picture you could even be opening yourself to 
> deadlocks.
> Threadlocals cost you memory but the client will not detect a delay. 
> They also don't use locks.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 


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


Mime
View raw message