Thanks for the heads up, I havn't been using any 'instance' variables.. but I was getting a little confused reading about all the woe's of threads and why my stuff appeared to be working =) Makes more sense now.
thanks! -David ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, December 22, 2003 12:35 PM Subject: Re: Example of a non-threadsafe Action? > Quoting David Erickson <[EMAIL PROTECTED]>: > > > Hey I have been reading a lot about threading lately from the JLS and > > otherwise.. but my question is what would be an example of a non-threadsafe > > action? Struts manual said that only one instance of an action exists in > > the JVM.. and when I run an action each thread creates its own versions of > > all the variables within the action correct? > > More precisely, you get per-thread *local* variables (i.e. those defined inside > a method). If you use *instance* variables (those defined in the class, rather > than inside the method, there is only one copy of those variables -- and you > get in trouble if you use those variables to store information that is specific > to a particular request. > > > So assuming I'm not accessing > > some outside 'global' variable, everything is inherintly threadsafe right? > > > > If anyone can give me an example of what 'not' to do that would help > > tremendously. > > thanks, > > David > > > > Consider the LogonAction class in the struts-example app. Note that the > "username" and "password" variables are defined inside the execute() method, so > they are local variables (and therefore have a copy per thread). > > What would happen to your logon processing if you moved those variable > declarations to be outside the method instead of inside? Then, if you had two > people logging on at the same time, the single copy of the username and > password variables would be at risk for getting scribbled on by the second > user. > > The most important rule for thread safety is to use local variables to store > anything that is specific to a particular request (using instance variables to > store read-only copies of things needed by multiple requests, on the other > hand, is fine). > > Craig > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
