Nubmer of servlet instance

[Jim Baker]

Hi,
The J2EE spec says there is only one instance
per servlet class running in one web container
for non single thread servlet.
Would this cause performance problem?
Jim

[Anthony Villanueva]

According to the Servlet 2.3 specs,

A servlet container may send concurrent requests through the service method of
the servlet. To handle the requests the developer of the servlet must make adequate
provisions for concurrent processing with multiple threads in the service method.

E pluribus unum, but it's really the other way around in this case.

The J2EE spec says there is only one instance per servlet class running in one web container for non single thread servlet.

To be perfectly nitpicky about this,

The servlet declaration which is part of the deployment descriptor of the web application
containing the servlet, as described in Chapter SRV.13, “Deployment Descriptor”, controls how the servlet container provides instances of the servlet.
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.

In short, for every distinct servlet-name you define in your web.xml for a given servlet class, you get a servlet instance that corresponds to that name. This is done so that multiple servlet instances of the same servlet class may possibly have different initial parameters (using the init-param tags).
-anthony
-anthony

[Jim Baker]

So there might be a problem when there is a huge
number of clients access to the same instance of
the servlet. Bottleneck? This is why front controller pattern may cause problems.

Correct me if I'm wrong.
JB

[Tim Holloway]

The key words are "adequate provisions".
Operating systems are FULL of spots where access is to a resource is enqueued, but they run efficiently. It's all in how you manage it.
As a general rule, the overhead for creating multiple servlet instances is likely to be a LOT more than well-placed synchronizations.

[Jim Baker]

Tim:
Are U saying well-placed synchronizations
provided by web server/OS are better
than multi-front controllers?
Anthony:
Are U saying we can control the number of
instance of servlet within web.xml? Could
U post a short example?
Thanks.
Jim

[Anthony Villanueva]

Are U saying we can control the number of instance of servlet within web.xml? Could U post a short example?

Well, control is such a strong word...

 
<servlet>
    <servlet-name>servletA</servlet-name>
    <servlet-class>SomeServlet</servlet-class>
</servlet>
<servlet>
    <servlet-name>servletB</servlet-name>
    <servlet-class>SomeServlet</servlet-class>
</servlet>
<servlet>
    <servlet-name>servletC</servlet-name>
    <servlet-class>SomeServlet</servlet-class>
</servlet>

Okay, I can access an instance of SomeServlet in Tomcat using the alias servletA, e.g.
http://localhost:8080/myContext/servlet/servletA
Similarly for the aliases servletB, servletC...
So it's not as if the distinct servlet instances pool together to help out. They live on separate little realms, invoked by different URLs, making life a bit harder for the poor container
-anthony

[Jim Baker]

It is still one instance of SomeServlet, but
just different names. Would this way help
when the client load is very high? Or It is
still a bottleneck.

[Tim Holloway]

Don't make things more complicated than they need to be.
What I meant was that use of synchronized code is not inherently bad. The key is to minimize the amount of time that you spend synchronized. If your app is full of sync code and/or the sync code is doing a lot of processing that doesn't actually NEED to be synchronized, then when multiple users execute the code, they will spend a lot of time waiting in line -- which will slow down response.
When you store data in the class or object instance, you have to synchronize access to it (or make it read-only). If you don't, the app will behave unpredicatably, and probably crash at random intervals.
So method-local storage and user-specific storage (request and session) are preferable, but this isn't an iron rule for efficiency. One of THE most efficient things you can do is use database connection pooling, and the connection pool pretty much HAS to be a synchronized object.
Bottom line. Don't kill yourself over "what-ifs". There's an old adage that goes "it's easier to make a simple, working app efficient than to make an 'efficient' app work". Design for simplicity, then stress-test the sucker. Chances are pretty good that the REAL choke points are going to be somewhere else anyway, but at least you'll know where to focus if you measure realities instead of tying yourself up in knots over theoreticals.
[ April 04, 2002: Message edited by: Tim Holloway ]