my dog learned polymorphism*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Error in EXAM STUDY KIT? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Error in EXAM STUDY KIT?" Watch "Error in EXAM STUDY KIT?" New topic
Author

Error in EXAM STUDY KIT?

Bill Skrypnyk
Greenhorn

Joined: Jul 04, 2003
Posts: 4
Is the following an error? Or can we assume that the same servlet may be declared under different names? (probably not a regular case).
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).
...
--Bill
Eddie Sheffield
Greenhorn

Joined: Oct 23, 2002
Posts: 21
No, the book is correct. That statement in the book is about a servlet implementing the SingleThreadModel. But note that the current SCWCD exam is based on Servlet 2.3 and JSP 1.2 specs. You're looking at Servlet 2.4 spec, and one of the differences is that the SingleThreadModel for servlets is deprecated. So looking at the same section in the Servlet 2.3 spec:

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.
HTH!
Eddie


"When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon. You just have to outrun the halfling."
Bill Skrypnyk
Greenhorn

Joined: Jul 04, 2003
Posts: 4
I can't see much of a difference in the specifications. 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. Thread-unsafe I read as NOT implementing the SingleThreadModel.
--Bill.
Eddie Sheffield
Greenhorn

Joined: Oct 23, 2002
Posts: 21
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.
Eddie
Bill Skrypnyk
Greenhorn

Joined: Jul 04, 2003
Posts: 4
Ah, you are right.
From the container's point of view:
SingleThreadModel = unsafe
Otherwise = safe
--Bill
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Error in EXAM STUDY KIT?
 
Similar Threads
Servlet instances
total servlet instance in distributable enviornment
Requests to Servlets
Servlet instances and its init method
Servlet Lifttime