-3
  HttpServletRequest request;
  HttpServletResponse response;

  public void doGet(HttpServletRequest request , HttpServlet response){
         this.request = request;
         this.response = response;
  }

What happens if this servlet receives multiple requests at a time?

We faced a response mismatch issue. Is this an issue?

kannanrbk
  • 6,964
  • 13
  • 53
  • 94

6 Answers6

4

Your web application container only loads one instance of a servlet.

To write thread-safe servlets, you should almost never use instance variables at all. Setting the request and response as instance variables is just plain wrong. The instance of the servlet doesn't belong to a single request.

If you need to make the elements of the request or response available to other methods, pass them to those methods. You don't need them as instance variables.

Rajesh J Advani
  • 5,585
  • 2
  • 23
  • 35
  • 1
    Try writing a non-trivial servlet with no instance variables; the servlet has to delegate control to *something* at some point (i.e. services). What you mean to say is to not use non-thread-safe instance variables. – skaffman May 19 '12 at 12:46
2

Of course it's an issue. A servlet is a singleton. The same servlet instance is used to handle all the requests to this servlet. And requests are of course handled concurrently. This means that thread1 will use the request and response normally handled by thread2 if you do that.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • By definition, Servlets are not Singletons. The Servlet API does not restrict the creation of a particular Servlet class to a single instance. A Container will usually create one instance of a servlet for each servlet declaration in the deployment descriptor. Whereas a singleton is a design pattern that restricts the creation of an object of its class to 1 and only 1. – verisimilitude May 19 '12 at 13:15
  • 1
    They are not singletons in the meaning of the GoF pattern, but they effectivly are because the container is **required** by the servlet spec to instantiate only one instance per servlet declaration. A singleton is not ONLY the GoF design pattern. Have you ever used a dependency injection framework like Spring or Guice? Never seen singleton being used in this context? – JB Nizet May 19 '12 at 13:18
  • Yes I have. I was trying to correlate to the GoF's definition of a singleton. and plus 1 for your elaboration :) – verisimilitude May 19 '12 at 13:25
  • 2
    So you chose one particular definition of singleton, and decided that the servlet didn't adhere to this particular definition, hence was not a singleton? That's like saying that a free beer is not free because it doesn't even have an open-source license. – JB Nizet May 19 '12 at 13:31
1

Quoting the Servlet Specification

"Each request and response object is valid only within the scope of a servlet’s service method, or within the scope of a filter’s doFilter method. Containers commonly recycle request objects in order to avoid the performance overhead of request object creation. The developer must be aware that maintaining references to request objects outside the scope described above is not recommended as it may have indeterminate results. "

verisimilitude
  • 5,077
  • 3
  • 30
  • 35
  • This doesn't has much to do with the OP's problem. If he nullified the instance variables at the end of `doGet()`, the scope of the request and response objects wouldn't be extended outside the service method, but he would still have big problems. – JB Nizet May 19 '12 at 13:24
  • Plausible. But still. If the spec is guaranteeing indeterminate results on saving references to these objects why to do so after all? – verisimilitude May 19 '12 at 13:29
  • It doesn't guarantee anything of the sort. You can save as many references as you want, so long you don't use these references outside the scope of the service method. You just have to do it in a thread-safe manner. Many frameworks store a reference to the request in a ThreadLocal variable, for example. – JB Nizet May 19 '12 at 13:33
  • I learnt it, thanks. In effect, this was turning into an argument, which i don't wanna be into. I critiquing yours and you mine. Thanks for all the clarifications. – verisimilitude May 19 '12 at 13:45
  • I didn't take it like that. I just like defending my point of view, that's all. – JB Nizet May 19 '12 at 13:47
0

This will definitely create issue, any instance variable is shared as servlet is singleton so concurrent request and response object will be overrided .

Subhrajyoti Majumder
  • 40,646
  • 13
  • 77
  • 103
0

What happens is that your servlet instantly becomes non-reentrant and will certainly fail the first time it is invoked by more that one client simultaneously. You must not do this.

user207421
  • 305,947
  • 44
  • 307
  • 483
-2

Its an issue and it is never advisable to declare HttpServletRequest request/HttpServletResponse response as an instance variable. Actually Servlet is implementing single thread model that means only one servlet instance is created. And one thread for each request. So if their are many requests then thr must be many threads and each sharing same servlet instance inturn it will create data mismatch or data inconsistency problem. Threads will work on the same instances.

Brijesh
  • 191
  • 1
  • 5
  • 11
  • 2
    single threaded model != singleton servlet. single-threaded model is precisely the model (that nobody uses because it's so inefficient) that guarantees that only one thread uses a given servlet. – JB Nizet May 19 '12 at 13:00
  • It's not advisable to go with the "single threaded implementation" either. It's deprecated. – verisimilitude May 19 '12 at 13:04
  • -1; this answer does not provide any value. As others already stated it's partially wrong. – home May 20 '12 at 15:56