On Tue, 21 Jan 2003, Adolfo Miguelez wrote:
> Date: Tue, 21 Jan 2003 21:47:53 +0000 > From: Adolfo Miguelez <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: (Un)expected behaviour in Action instance variables? > > > Thanks for your response Craig, > > actually I have read about performance problems of ThreadLocals. I have > tested with JDK 1.2.2, and the patch works, but I do not want to slow down > the app for this issue, so still looking for a better solution. > > Anyway, I wonder why by inspecting a thread, we can not know which one > request belongs to, or in other words take the request (or session) instance > from the thread instance. It seems for me a little stupid to pass the > HttpServletRequest in both directions: > > * BaseAction -> ExtendedAction: in doPerform() called from perform(), and > * ExtendedAction -> BaseAction: in my call to getData(...) > > when already sevlet engine ¿should? know it, from the thread. > The problem is not whether its known or not -- its whether the single instance of your Action is used by more than one thread at the same time or not. Since Actions *are* used that way, your only choices are a ThreadLocal or passing the parameters around. > Is not there a table request/thread relationship somewhere which I could > check from my base action? That's essentially what a ThreadLocal does -- it creates a HashMap that is keyed by the thread so that it keeps a separate value per thread. But, as I said earlier, the maintainability of this code will be lower than the maintainability of code that explicitly passes arguments -- IMHO that would be a fatal flaw for ThreadLocal even if it *was* performance free. > > Anyone else figures out a solution? > > Otherwise I would go for passing getData(request), but is embarrassing since > some apps already began should be modified. > Programming in a multithread environment is not the same as programming in a single thread environment. > Thanks in advance, > > Adolfo. > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
