Hello, I would like to add some comments about the SingleThreadModel (STM). You "case study analysis" is incomplete.
> Question 2)can anybody explain me how a servlet containerhandles multiple request from diff clients > when > case a)there is only one instance in pool and there r 1000 requests > sub case1: if servlet method is synchronised.(SingleThreadModel interface) Careful with your wording here. When you say the "servlet (sic, should be service) method is synchronised" that is *not* equivalent to saying that a servlet implements the STM. > sub case2: non synchronised service > > case b)there r 100 instance of servlet in pool and 1000 requests > and non synchronised service Here is how I think of the possible cases: Scenario: a single *servlet definition* and 1000 concurrent requests Case A) The servlet has been properly designed/coded for concurrency. In this case, the servlet does not use STM so the Web container will only create one instance and all requests will be handled concurrently by that instance. Ideal performance. Case B) The servlet's service method (or doGet/doPost/etc) is synchronized In this case, the servlet does not use STM so the Web container will only create one instance and each request is serialized through the service method of that instance. Poor performance. Case C) The servlet implements STM and Web container serializes access In this case the each request is serialized through the service method of a single instance of the servlet definition. Poor performance. Case D) The servlet implements STM and Web container uses a pool of 100 In this case the first 100 requests are immediately processed, the other 900 are queued until the servlet instances are returned to the pool. Decent performance. Clearly cases B and C are roughly identical in performance. Case D is a little bit better. And Case A is clearly the best solution. But performance is only one issue. Code reliability is more important in my opinion. You (the developer) do not know how STM is implemented in the Web container; it could be serialization of requests or concurrent requests handled by independent instances from a pool. This can cause portability problems when you move from one container to another. What does STM protect? Answer: instance variables (only). The implications of this statement are subtle. First of all, suppose that you use an instance variable to count the number of accesses to a given servlet. What happens if you use STM and the Web container serializes access to a single servlet? In this case, your instance variable will have reliable semantics. However, what happens if you use STM and the Web container uses a pool of instances? Does your counting instance variable have the same semantics? I would argue NO because the count is now distributed across multiple instances. What is really bad is that you could have your counting servlet working in one container, but when you move your servlet to another container it might fail (due to the change in semantics of the STM impl). Furthermore, are instance variables the *only* scope in which concurrent contention for shared data exists? Definitely not! There are three other servlet "scopes" that also suffer from multi-threading problems. These are: class/static variables, context attributes, and session attributes. Moreover, what if your instance variables refer to complex Java objects? If you have a pool of servlet instances all refering to the same object, then access to the methods of *that* object could corrupt your application if that object is not properly designed for concurrent access. It is for these reasons that STM is deprecated in servlet spec v2.4. My suggestion is to spend some time learning proper concurrency control, patterns, and Java language features. I would recommend Doug Lea's seminal (but highly technical and advanced) book "Concurrent Programming in Java (2nd Ed)" Good luck, Bryan ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
