While reading through “184.108.40.206 Multithreading Issues” in “JavaServlet 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.
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.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com