*
The moose likes Servlets and the fly likes Nubmer of servlet instance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Nubmer of servlet instance" Watch "Nubmer of servlet instance" New topic
Author

Nubmer of servlet instance

Jim Baker
Ranch Hand

Joined: Mar 10, 2002
Posts: 177
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
Ranch Hand

Joined: Mar 22, 2002
Posts: 1055
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
Ranch Hand

Joined: Mar 10, 2002
Posts: 177
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Jim Baker
Ranch Hand

Joined: Mar 10, 2002
Posts: 177
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
Ranch Hand

Joined: Mar 22, 2002
Posts: 1055
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...

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
Ranch Hand

Joined: Mar 10, 2002
Posts: 177
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

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 ]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Nubmer of servlet instance
 
Similar Threads
How is Servlet a singleton?
how counter variable works in jsp
Servlet instances and its init method
servlet instance
Multiple Servlet Instance?