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 Hirneisenno...@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 Hirneisenno...@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
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 ThreadLocalLong projectId = new ThreadLocalLong(); @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 Hirneisenno...@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 Hirneisenno...@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
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 ThreadLocalLong projectId = new ThreadLocalLong(); @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 Hirneisenno...@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 Hirneisenno...@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