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_str...@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:davelnew...@gmail.com] > > Gesendet: Samstag, 18. September 2010 14:07 > > An: Struts Users Mailing List; no...@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<no...@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:davelnew...@gmail.com] > > Gesendet: Samstag, 18. September 2010 13:47 > > An: no...@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"<no...@s2you.de> wrote: > >> Nobody here who can help ? > >> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Norbert Hirneisen [mailto:no...@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: no...@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-unsubscr...@struts.apache.org > >>> For additional commands, e-mail: user-h...@struts.apache.org > >>> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> For additional commands, e-mail: user-h...@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-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
