Thanks for the hint to ThreadLocals.
 
I´m using the projectId in the subclassed action classes to identify a project,
generate project-related URLs and to query the database for project-related
data. I´m needing the projectId in nearly every subclassed action.
 
It would be very convenient to retrieve the projectId in a centralized way in
the base class and to make it available to the subclasses.
It´s the same with the userId of the logged-in users.
 
Would it be good design to define projectId as a ThreadLocals in the base class
or would it be better (and simpler) to just store the data in the
session-context ?
 
Can you give me some hints as to the pro and cons of both methods ?
 
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
>





Reply via email to