Servlet instances

when 100 client hits to single servlet ow many instace will be there i mean one or 100,

if one then what about the object pool

why we need to make a servlet to threadsafe

any help regarding to this point.

servlet does the object pooling itself. there is some kind of pooling mechanism given in the servlet container. container manages all the instances of servlet, and knows whether or not to instantiate a new servlet object.

as we could have more than one client served by the same servlet and we have something inside the servlet which we want to make threadsafe. we code it as threadsafe.

If I'm not mistaken, there will only be 1 instance of the servlet. But instead, the container will create new threads to service the requests. And, its 1 new thread per new request, regardless of which client issuing the requests.

HTH.

thanx for pointin out.

yeah 1 instance but might be more than 1 thread.

i was just writing instance and instance and instance ...... but its thread not an instance.

It also depends on the container implementation..Container can create multiple instances rather that using multiple threads for servicing multiple request at a time.

cheers.

Neeraj.

If you make your servlet implement the SingleThreadModel interface, the container will ensure thread safety. It can do this by:
- queueing requests to one instance of the servlet
- creating multiple instances of a servlet

Note: SingleThreadModel is deprecated in the Servlet 2.4 specification

How about tomcat implementation?? does it make multiple instances of servlet or just do it with multiple threads?
[ September 20, 2004: Message edited by: adeel ansari ]

Originally posted by Neeraj Vij:
It also depends on the container implementation..Container can create multiple instances rather that using multiple threads for servicing multiple request at a time.

cheers.
Neeraj.

Container do use multiple threads for servicing. it may use multiple instances of servlet as well in some cases that i dont know. But there is a new process for every request.

i think in the case of multiple instances. it is like one instance per thread.

this is, what i know.
[ September 20, 2004: Message edited by: adeel ansari ]

yeah i was thinking in a right way.

please refer to page no. 420 of

Servlets and Java Server Pages
The J2EE Technology Web Tier

By: Jayson Falkner, Kevin Jones
ISBN: 0321136497

you can get it for free from theserverside.com

just to add up..

and that process could be a different thread or a different instance depending on how container handles the load of request..

cheers

Neeraj.

couldn't get you.

process could be a different instance

how can a process could be an instance??

i think

Process meant, the way container would handle the client requests..

for example...In a distributed environment, client request are processed by different instances in different containers though both are the same servlets..

I hope this clears your doubt..

rgds,

Neeraj

Hello,

It's true that at a time one servlet instance is created and for each requests, thread is created. Again, this depends upon the container implementation, but most of the servlet containers are doing the same way. If the servlet is thread safe, i.e. implementing SingleThreadModel interface, there will be a pool of servlet instances. Because the first case is not possible here.

Originally posted by Neeraj Vij:
Process meant, the way container would handle the client requests..

for example...In a distributed environment, client request are processed by different instances in different containers though both are the same servlets..

I hope this clears your doubt..

rgds,
Neeraj

processed by different instance, and
process could be a different instance

are quite different things. But again I would like to refer you all to that book, i mentioned above. then there would be no more ambiguity.
thanx

Originally posted by Sheldon Fernandes:
If you make your servlet implement the SingleThreadModel interface, the container will ensure thread safety. It can do this by:
- queueing requests to one instance of the servlet
- creating multiple instances of a servlet

Note: SingleThreadModel is deprecated in the Servlet 2.4 specification

You should *never* implement the SingleThreadModel. It does not help you in the thread safety issue at all.

servlet engines are permitted (but not required) to create multiple servlet instances....

and for performance requirement of your appliaction... most of the servlet containers provides you with the facility to configure multiple instances..
it depends on the developer to evaluate his requirement...

Cheers
Neeraj.

servlet engines are permitted (but not required) to create multiple servlet instance

This statement is wrong as it stands, I wonder why it keeps showing up?
The servlet API REQUIRES that a single servlet engine only create a single instance of a servlet. (SingleThreadModel excepted)
Where do you people get these weird ideas? Download the real api documentation from this Sun site and stop flailing about. I refer you to the SRV2.2 paragraph "Number of Instances".
Bill

Hi,

I found this from "Core Servlets and JavaServer Pages " page 259..

See http://www.coreservlets.com for details.

regards,
Neeraj.

Hi william,

There are servlet containers which allow you configure number of insatnces..

please correct me, if I am wrong.

Regards,
Neeraj.

Vij have you downloaded that book which i have refered you?? get that please, its for free, and i hope it helps.

ya buddy... but I have not started reading it..

rgds,
Neeraj.

Hi all,

An article at "http://java.sun.com/developer/technicalArticles/Servlets/servletapi/"

this ia a partial text of that article.

"
Lifecycle Clarifications
Some additional clarifications have been made in the Java Servlet API 2.2 specification pertaining to Web apps and the servlet lifecycle.

It's now defined that, for servlets that don't implement SingleThreadModel, there's exactly one instance of a servlet per definition (that is, registered name) per context. Previously, the server could optionally create multiple instances. This new, stricter rule allows servlets to use instance variables to hold state associated with a particular servlet definition. For example, counter servlets can store their count in instance variables, and each registered name for the counter can maintain its own count. (This was how nearly everyone wrote servlets with versions 2.0 and 2.1 of the API; the difference is that now this technique is guaranteed to work.)

It's also defined that Web servers must guarantee that servlets sharing information via user sessions or servlet contexts must not experience unexpected ClassCastExceptions. Such exceptions occurred previously due to servlets being loaded by different ClassLoader instances -- remember, classes loaded by two different class loaders cannot be cast to one another. In effect, this new rule means that, when one servlet class is reloaded, all the classes of the entire context have to be reloaded. This causes an unfortunate performance penalty, but one that should only be paid during development and that can be justified by the easier programming it allows"

rgds,
Neeraj.

there is not necessarilly a new process for every request.
Such will happen only (in general) if the JVM creates a new process for every thread (which happens on some JVM implementations but not others).

If you run Tomcat under Windows using the Sun JVM for example you will have a single operating system process which handles the entire application server.
Under Linux the same will create multiple processes because of the way Linux handles multithreading.

yeah quite right. when it comes to threading java becomes somehow platform dependent. because thread scheduling and management may differ platform to platform.