• 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Servlet Instance Pool - Java Servlet Specification V3.0 - 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 “ 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.

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.
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic