There are no multiple instances of a servlet to process requests concurrently. Servlets should be stateless and their code should be unsynchronized.
Mukta Josh wrote:I meant the way container implements servlet instance creation. How concurrency will get affected if multiple instances of same servlet are created to process concurrent requests.
Concurrency is in no way improved. It may just lead to errors because some web applications depend on the fact that there is only one instance of a bean that has application scope.
Ron McLeod wrote:I believe that a container normally creates only a single instance of the servlet class, and has multiple threads which can concurrently call the instance's service method.
While I believe that this is true in practice, the last time I read the spec (which admittedly was a long time ago) a container was free to create multiple instances for whatever reason it deemed suitable. I could be wrong, but I seem to remember this.
Point is, if a servlet is written properly to be stateless, it shouldn't matter.
This means there is absolutely no difference as long as the servlet is stateless. If the servlet implements SingleThreadModel and is NOT stateless, you need to synchronize state between the different servlet instances (which will lead to massive performance issues), or suffer race conditions. As you can see, SingleThreadModel is pretty useless, and that's probably why it was deprecated a long time ago.
you should just assume that you only have one instance of a declared servlet per container. The reason for this is that you only have to initialize a servlet once, which can be a very expensive operation.
Stephan van Hulst wrote:Hmm I just read part of the spec. Servlet containers must only ever create one instance of a declared servlet, except if the servlet implements SingleThreadModel, as Mukta already pointed out. If a servlet implements SingleThreadModel, its service() method is run by no more than one thread at a time, but the servlet container is free to create multiple instances of the servlet to handle requests concurrently anyway.
Ah! Thanks for looking up the details.
What I understand from above discussion is, if my servlet is stateless (which means it doesn't have any instance or class variables) then even if container creates multiple instances of same servlet for different requests, concurrency is not lost.But then the mention and recommendation in servlet specification to follow one instance-multiple threads policy, is it just because creating servlet instance is expensive operation or am I missing something here?
Please correct me if I have understood wrong.
Mukta Josh wrote:if my servlet is stateless (which means it doesn't have any instance or class variables
That's not what stateless means. You can have fields, their values just shouldn't change between calls.
if container creates multiple instances of same servlet for different requests, concurrency is not lost.
I don't know what you mean by "lost concurrency". When does one "lose concurrency"?
But then the mention and recommendation in servlet specification to follow one instance-multiple threads policy, is it just because creating servlet instance is expensive operation or am I missing something here?
Web applications need to be able to handle multiple requests concurrently to be effective in any kind of production scenario. Regardless of whether you create one or multiple servlets, they simply need to be stateless to perform well. If they are stateless, then there is absolutely zero benefit to creating more than just one instance, and only drawbacks if they are expensive to initialize. Besides that, servlets are not guaranteed to be stateless. If you really wanted to, you could make a stateful servlet and synchronize the different requests. It would be slow, but it would at least it would work without errors, but ONLY IF all requests are being sent to the same servlet instance.