• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Servlet Instance Pool - Java Servlet Specification V3.0 - 2.3.3.1 Multithreading Issues

 
Ranch Hand
Posts: 182
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

While reading through “2.3.3.1 Multithreading Issues” in “Java Servlet Specification V3.0” below statement is confusing me .

For servlets not implementing the SingleThreadModel interface, if the service method (or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class) has been defined with the synchronized keyword, the servlet container cannot use the instance pool approach, but must serialize requests through it.


What does it mean by “Servlet Instance Pool”. As we know, there can be only one Servlet instance per declaration per JVM (in an non-distributed environment). Was “Thread Pool” misspelled as “Instance Pool” here? I believe Thread Pool also does not make any sense here. Tried search the web, but couldn’t get the relevant answers.

Thanks,
A.A.Anbarasu
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are right, it`s pretty confusing.

The case is that (as you wrote), when Servlet doesn`t implement SingleThreadModel, only one instance of it will be created. And if you synchronize one of it`s methods (service(..), doPost(..), etc), container won`t be abe to use full potential of concurrent executions. Request to this servlets will be serialized, because each request-thread will block servlet for the time of it`s execution.
This situation is even worse than implementing SingleThreadModel. When your servlet implement it, you mark it for the container and the container can create many instances of the Servlet and pool them, so each thread will work on different servlet instance and it won`t be blocked (of course if there will be enough servlet instances).

So, by 'cannot use the instance pool approach', I would understand that:
-container won`t be able to gain benefits from concurrent threads working on one servlet instance.
 
It's feeding time! Give me the food you were going to give to this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic