This is an excerpt from EXAM STUDY KIT by Deshmukh & Malavia (p.195):
But if the container decides to create a pool of instances of the thread-unsafe servlet,
then each servlet instance will have its own copy of the count variable.
The servlet specification 2.4 states (SRV.2.2):
For a servlet not hosted in a distributed environment (the default), the servlet
container must use only one instance per servlet declaration.
In the case where a servlet was deployed as part of an application marked in
the deployment descriptor as distributable, a container may have only one instance
per servlet declaration per Java Virtual Machine (JVMTM).
SRV.2.2 Number of Instances
For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.
In the case where a servlet was deployed as part of an application marked in the deployment descriptor as distributable, a container may have only one instance per servlet declaration per virtual machine (VM). However, if the servlet in a distributable application implements the SingleThreadModel interface, the container may instantiate multiple instances of that servlet in each VM of the container.
Also, under either 2.3 or 2.4, it is perfectly acceptable to have the same servlet class deployed multiple times under different names by specifying multiple servlet entries in the deployment descriptor. This is useful if, for example, you resuse the same servlet in different places and with different initialization parms. In this case there will be multiple instances of the class instantiated, but only once per declaration. That's assuming the servlet is NOT a SingleThreadModel servlet - if it is then pooling may be used as described.
So until Sun updates the exam to 2.4 (and I haven't heard of that happening anytime soon) stick to the Servlet 2.3 spec for study purposes.
Originally posted by Bill Skrypnyk:
I can't see much of a difference in the specifications.
Not a lot of difference, except the later spec makes no mention of the SingleThreadModel. The info from the book only makes sense in light of the earlier spec with the SingleThreadModel info.
I think the ambiguity comes in around the 'pool of instances' wording. Having the same servlet deployed under different names and having one instance per declaration is not the same as having a pool of instances of **thread-unsafe** servlets.
Very true! They are two distinct concepts. You can have multiple deployments of either thread-safe or thread-unsafe (SingleThreadModel) servlets under different names in the same web app.
Thread-unsafe I read as NOT implementing the SingleThreadModel.
That's backwards. If you DON'T implement SingleThreadModel, you're telling the container that the servlet IS thread-safe, and therefore (by the spec) the container must service concurrent requests to the specific servlet deployment via multiple threads running over the SAME instance of the servlet. If the same servlet class is deployed several times under different names, there is a 1-to-1 correspondence of deployment to instance.
If you DO implement SingleThreadModel, the implication is that the servlet is NOT thread safe and each concurrent request must be serviced by a separate servlet instance. These instances may be pooled by the container. In this case there would be a 1-to-1 correspondence of deployment to pool. If pooling is not used, then the requests would be serialized to a single instance.