1) if by 'localized' you mean "I've moved the variables from outside the doGet()/doPost() methods, to inside those methods"... then this is why there is no 'data corruption' (due to multithreading issues), and it's why you don't require synchronized access to those variables. I will probably explain this perhaps not 100% correctly, but someone will catch me when I fall.. ;)
A user request = one java thread. If more than one user requests something from your servlet, that means (potentially) more than one thread in your servlet methods. If one thread alters a variable outside of the doGet()/doPost() methods, then this modifies that variable for ALL threads, and thus, you get data confusion/corruption. It's a simple matter of scope. If the thread alters a variable within the method, then this variable is located in the method 'stack', and altering its value will only alter the data for that particular thread. So it is literally impossible to 'confuse' the data, if all of your variables are declared within the method. Again, a matter of scope. 2) jmeter is an open-source web-testing tool. Fairly simple, and works quite nicely. You can use it to load test an application, and can configure it to launch X threads simulatenously. This would give you a fair chance of testing concurrency issues. 'X' will be solely determined by how much CPU and memory your testing box has. Jmeter lets you slave multiple workstations to use as load generators, so X can become quite high (which is good). You can also configure jmeter to check the results of a particular web request. So for example, if a user submits a search to search.jsp with a certain set of search values... and you expect a result in your page of : <p>your search returned <b>500</b> results</p> Then you can actually test for this string in the returned webpage. If the '500' is something else (say '450'), then you can begin to suspect concurrency issues. (Because perhaps another of your simultaneous users used a different set of parameters, say ones that would produce '450'). > -----Original Message----- > From: kwirirai [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 11, 2004 11:32 AM > To: Tomcat Users List > Subject: Re: Servlet thread safety in Tomcat > > > Thanks to All for your help ! :-) > Sofar it seems to be working ,no data corruption,I localized all > variables ,put in some synchronized blocks,removed them > again(synchronized blocks) and seems to work, but not sure > why without > the synchrozed blocks its working . :-\ > Is there free software that I can use to test the concurrency > issues,because at the moment I am trying to test all this using two > client machines and this does not work at all.Software that > can create > many simultanoeus connections sending in the request parameters to > Tomcat would do well for testing > . > > > > > Shapira, Yoav wrote: > > >Howdy, > > > > > > > >>this has made me think a lot about threading , it is really > >>complicated , I have researched about it but never found a clean > >>solution to > >> > >> > > > >Threading is complicated, yes, and difficult to do well. > Which is why > >when possible you should let someone else do the work for > you and use a > >library like Doug Lea's util.concurrent, which is now > >java.util.concurrent in JDK 1.5. It has thread pools, executors, > >locks, etc so you don't have to write any of this sync code yourself. > > > >Yoav Shapira > > > > > > > > > >This e-mail, including any attachments, is a confidential business > >communication, and may contain information that is confidential, > >proprietary and/or privileged. This e-mail is intended only for the > >individual(s) to whom it is addressed, and may not be saved, copied, > >printed, disclosed or used by anyone else. If you are not the(an) > >intended recipient, please immediately delete this e-mail from your > >computer system and notify the sender. Thank you. > > > > > >--------------------------------------------------------------------- > >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]
