tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Curwen" <mi...@gb-im.com>
Subject RE: Servlet thread safety in Tomcat
Date Wed, 11 Feb 2004 19:49:42 GMT
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:kwirirai@designat7.co.zw] 
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
> >  
> >
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message