• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Nubmer of servlet instance

 
Jim Baker
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1055
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18100
51
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1055
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18100
51
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic