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.
You definitely do not need synchronized on local variables.
However, you DO need it if you use something "shared" among the requests. That is, outside the local scope.
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.
No objection ;-)
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').
It will not be easy to pinpoint concurrency problems using JMeter.
The procedure is roughly what Mike described. However, you will need to know your data very well, and possibly output some debugging info in your pages (maybe inside a HTML comment).
It will not be easy.
From my experience, JMeter is really great for cases where border conditions make the server fail with a 500. You stress it, and it is more likely to fail. But detecting "slight" errors in the information contained in a page is a different business.
I wish I could give you an alternative, but I am afraid I know none.
Yours,
Antonio Fiol
smime.p7s
Description: S/MIME Cryptographic Signature
