Re: AW: AW: AW: Struts 1 and thread safety
On 9/19/2010 5:12 AM, Norbert Hirneisen wrote:
After some more thinking I have come up with the following solution:
- using session-context to store the loggedin user (user object and userId)
- using ThreadLocals to store the project used in the request.
Considering users who use multiple browser windows to visit several of my
projects parallel storing the projectId in the session would be confusing.
So I have modified my DispatchAction like this:
public abstract class DispatchAction extends Action {
private static ThreadLocal projectId = new ThreadLocal();
@Override
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
...
long pid = Project.getIdFromRequest(request);
projectId.set(new Long(pid));
...
return forward;
}
/**
* @return the projectId
*/
protected static long getProjectId() {
return projectId.get();
}
}
And in the subclass I use
long projectId = super.getProjectId();
--
Something wrong with that approach ?
Thanks in advance,
Norbert
-Ursprüngliche Nachricht-
Von: Norbert Hirneisen [mailto:no...@s2you.de]
Gesendet: Sonntag, 19. September 2010 09:42
An: 'Struts Users Mailing List'
Betreff: AW: AW: AW: Struts 1 and thread safety
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 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" 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
AW: AW: AW: Struts 1 and thread safety
After some more thinking I have come up with the following solution:
- using session-context to store the loggedin user (user object and userId)
- using ThreadLocals to store the project used in the request.
Considering users who use multiple browser windows to visit several of my
projects parallel storing the projectId in the session would be confusing.
So I have modified my DispatchAction like this:
public abstract class DispatchAction extends Action {
private static ThreadLocal projectId = new ThreadLocal();
@Override
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
...
long pid = Project.getIdFromRequest(request);
projectId.set(new Long(pid));
...
return forward;
}
/**
* @return the projectId
*/
protected static long getProjectId() {
return projectId.get();
}
}
And in the subclass I use
long projectId = super.getProjectId();
--
Something wrong with that approach ?
Thanks in advance,
Norbert
> -Ursprüngliche Nachricht-
> Von: Norbert Hirneisen [mailto:no...@s2you.de]
> Gesendet: Sonntag, 19. September 2010 09:42
> An: 'Struts Users Mailing List'
> Betreff: AW: AW: AW: Struts 1 and thread safety
>
>
> 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 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
&
AW: AW: AW: Struts 1 and thread safety
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 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" 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 V
