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<Long> projectId = new ThreadLocal<Long>();
@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<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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
I don't see a hazzard -- the threadlocals will be cleared when your
client threads die.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
