Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of davelnewton@gmail.com
 designates 209.85.212.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=mnHgZXbXgcoIPe8dt0GgRe0ylHxeX/ch1/9m+qnShZWIrnIToXy8cbi/wD/2Y+TooH
         K++1P0iTY+/DCperDyKA3MZtH5ZpgCCvQISOvcXmRrISIDG3FEN8UYS5fT8HEFT+5bdx
         HKalivGzA4NMLTI+0jrp5TS0WMw9Zqz69E59Q=
MIME-Version: 1.0
In-Reply-To: <02ae01cb572e$1e38c460$ed00a8c0@nserver>
References: <AANLkTik5xWtaOHUSOmQ6N-tyiomRUiJk1Dw+FOf=pCSi@mail.gmail.com>
	<02ae01cb572e$1e38c460$ed00a8c0@nserver>
Date: Sat, 18 Sep 2010 08:59:21 -0400
Message-ID: <AANLkTikqXVTiaa6OcSXZJ5N2WNLhyoyUvWmaRVXdm6Ts@mail.gmail.com>
Subject: Re: AW: Struts 1 and thread safety
From: Dave Newton <davelnewton@gmail.com>
To: Struts Users Mailing List <user@struts.apache.org>, nobbi@s2you.de
Content-Type: multipart/alternative; boundary=0016369f9b5e7a94300490883fbb

--0016369f9b5e7a94300490883fbb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, synchronizing in this way could potentially be bad.

On Sat, Sep 18, 2010 at 8:36 AM, Norbert Hirneisen <nobbi@s2you.de> wrote:

> Just another question regarding this context:
>
> the original code has been written by a colleague.
> Now I=B4m intrigued if setting the execute-Method in the base class withi=
n a
> synchronized block makes sense ?!
> As far as I=B4m 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=FCngliche 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 =3D Project.getIdFromRequest(request);
>
> in every subclass because there is no thread-safe way to use a class fiel=
d
> 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=FCngliche 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=FCngliche 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=B4m not sure if
> >> this approach is
> >> thread safe on a request level.
> >> Abbreviated example:
> >>
> >> public abstract class DispatchAction extends Action {
> >> ....
> >> protected volatile long projectId =3D -1;
> >> ....
> >>
> >> @Override
> >> synchronized public ActionForward execute(
> >> ActionMapping mapping,
> >> ActionForm form,
> >> HttpServletRequest request,
> >> HttpServletResponse response)
> >> throws Exception {
> >> ...
> >> long projectId =3D 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=E4hler: www.falterfunde.de
> >> Wanderfalter: www.science4you.org/platform/monitoring/index.do
> >> Tagfalter-Monitoring Deutschland:
> >> www.science4you.org/platform/tmd/tmd-top/index.do
> >> Infos =FCber gesch=FCtzte Arten ? http://www.wisia.de
> >>
> >> Norbert Hirneisen
> >> Science & Communications
> >>
> >> von-M=FCllenark-Str. 19
> >> 53179 Bonn
> >> Tel. 0228/6194930
> >> Ust.ID-Nr. DE237150377
> >>
> >> Der Inhalt dieser Mitteilung ist nur f=FCr obigen Adressaten
> >> bestimmt und streng
> >> vertraulich. Eine Weitergabe oder Vervielf=E4ltigung durch
> >> andere als den
> >> Adressaten ist verboten! Sollten Sie diese Nachricht
> >> irrt=FCmlich erhalten haben,
> >> ersuchen wir Sie um sofortige Verst=E4ndigung und darum,
> >> s=E4mtliche Dateien von
> >> Ihrem Computer zu l=F6schen. Unsere E-Mail sind gepr=FCft,
> >> erfolgen jedoch ohne
> >> Gew=E4hr.
> >>
> >> 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
> >
>
>
>
>
>
>

--0016369f9b5e7a94300490883fbb--