Thread A : The Container calls init() on the servlet instance after the servlet instance is created but before the servlet can service any client requests. If you have initialization code (like getting a database connection or registering yourself with other objects), then you'll override the init() method in your servlet class. Otherwise, the init() method from GenericServlet runs.
Thread B: When the first client request comes in, the Container starts (or finds) a thread and causes the servlet's service() method to be invoked. You normally will NOT override the service() method, so the one from HttpServlet will run. The service() method figures out which HTTP method (GET, POST, etc.) is in the request, and invokes the matching doGetQ or
doPostQ method. The doGet() and doPost() inside HttpServlet don't do anything, so you have to override one or both.
Thread C: When the second (and all other) client requests come in, the Container again creates or finds a another thread and causes the servlet's service() method to be invoked.
So, the serviceQ -> doGet() method sequence happens each time there's a client request. At any given time, you'll have at least as many runnable threads as there are client requests,
limited by the resources or policies/configuration of the Container.
SO CAN WE INTERPRET THAT FOR EACH SERVLET A THREAD IS CREATED HAVING ITS OWN INIT() BEING CALLED BEFORE REQUESTS COMES IN & AFTER THE REQUESTS COME IN ANOTHER SECOND THREAD IS CREATED FOR THAT SERVLET???
Thanks in advance..
P.S= this book is awesome , soon will be appearing for scwcd.
Hi Mudassar, welcome to the ranch!
You are right! the most important point here is that Servlet.init(ServletConfig config) will be called ONLY ONCE in the life cycle of a servlet. Also there will be only one instance of a servlet at a time (provided the app is not a distributable one). For each request coming from client, the container will create separate Threads, create objects for HttpServletRequest and HttpServletResponse and pass to the service method which will be run in that new Thread. The service() method will decide which doXxx() method to call!. For example, if there are 10 requests coming for a servlet, container will create 10 separate Threads and run the service() method in 10 separate Threads. But there will be only a single instance of the servlet class.
Hello Mr.Raeev, I am quite delighted with your quick & informative response , but it seems my query has gone misinterpreted. Indeed a single instance will be created but the number of threads created is the concerned ambiguity. On reading the texts of the book it infers( or thats what I think it is) that initially a thread is created automatically for each servlet where in the init() is called (Thread A : The Container calls init() on the servlet instance after the servlet instance is created but before the servlet can service any client requests.) . Further as requests come in further threads are created.(Thread B: When the first client request comes in, the Container starts (or finds) a thread and causes the servlet's service() method to be invoked.) Hence for a particular servlet Thread A is created initially by the container further Thread B is created for 1st request coming from client. Therefore two threads created till the request.
I do believe this cannot happen but certain clarification is required since the book seems to support the above scenario.
Thanks for the response ,looking forward for the same.
Hello Mudassar, I think the scenario explained in the book is possible. You need a Thread to start with (lets say Thread A) to load the servlet class, call init() method etc. After that it becomes a servlet. So far Thread A is running (along with other JVM / container threads). When the first client request comes in, container creates a separate thread (or finds another Thread) which is Thread B and this will be used to call service() method. For the second client request, Thread C is created. When the requests are done, Thread B and Thread C are completed. Thread A still remains. When servlet life ends, it will call Servlet.destroy() and ThreadA completes (maybe).
I think you're putting too much emphasis on what the book calls "Thread A". The important thing to note is that the thread that creates the servlet and calls init will not be used to execute any actual requests (meaning, it is different from any request-servicing threads). Whether "Thread A" is still alive when requests are being serviced is irrelevant. It may be, or it may not be (which I think is more likely, but that's entirely up to the servlet container).
Joined: Jul 04, 2010
Thanks Rajeev & Dittmer for the response. Now The main assumption which I need to verify is when the request comes in, hten1st thread is created for the servlet calling its init() further a second thread is created for the service() method OR is it that initially all the servlet have their individual threads created having called their individual init() called further as request comes in further threads are created ( doubtfull of this one happening because all the servlets would be initialized which would crash down the server ).
Joined: Mar 22, 2005
when the request comes in, hten1st thread is created for the servlet calling its init() further a second thread is created for the service() method OR is it that initially all the servlet have their individual threads created having called their individual init() called further as request comes in further threads are created ( doubtfull of this one happening because all the servlets would be initialized which would crash down the server ).
Firstly, the calling of the init method is not strongly correlated with requests coming in; did you understand that part in my previous post?
Secondly, only a single servlet instance is created -no matter how many requests are coming in- so there's only a single time that init is called.
Lastly, initializing even a hundred servlets should not do anything bad to a server, except delay the responses. Of course, if the servlets take a long time to initialize, then they should be declared as load-on-startup, or -even better- whatever is initialized should be moved to a context listener.