This week's book giveaway is in the Beginning Java forum.
We're giving away four copies of Murach's Java Programming and have Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Java Programming this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

About Servlet Implementation  RSS feed

 
Mukta Josh
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why servlet implementation is based on singleton pattern?
If multiple instances of servlet are created to process requests concurrently(which is one way of implementing singleThreadModel), how concurrency is lost?

Thanks,
Mukta
 
Stephan van Hulst
Saloon Keeper
Posts: 7470
133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Servlet implementations are not necessarily based on singletons. You can, but it's a bad idea. Most of the time, you would use an MVC framework that's built on top of servlets, and inject dependencies that you annotate with a scope.

There are no multiple instances of a servlet to process requests concurrently. Servlets should be stateless and their code should be unsynchronized.
 
Mukta Josh
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By servlet implementation, I did not mean how servlet developers should implement it.
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.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66041
140
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If servlets are written correctly (as Stephan posted) then concurrency is not affected if the container decides to create multiple servlet instances.
 
Stephan van Hulst
Saloon Keeper
Posts: 7470
133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 1527
210
Android Angular Framework Eclipse IDE Java Linux MySQL Database Redhat TypeScript
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66041
140
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stephan van Hulst
Saloon Keeper
Posts: 7470
133
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

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.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66041
140
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mukta Josh
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you so much for your response guys!!

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.
 
Stephan van Hulst
Saloon Keeper
Posts: 7470
133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Do not threaten THIS beaver! Not even with this tiny ad:
Thoughts on deprecation in Java
https://coderanch.com/t/683016/java/Deprecation-Java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!