Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When is a Servlet destroyed?

 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm reading through Head First Servlets and JSP and I'm a little puzzled by something. Let me know if I have my facts straight or not, please.

First, the container is started (such as Tomcat) and it creates and initializes any servlets that are deployed within it. Once initialized, a servlet can respond to various requests through execution of the doGet and doPost methods. I believe this information is accurate, but let me know if I've got this wrong.

My question is, when is the destroy() method invoked? I'm guessing that this is invoked when the container is shut down. Or, possibly, is it invoked when the servlet is done processing all active requests. If that's the case, though, then wouldn't the container have to create a new servlet any time a request came in for a servlet that wasn't currently handling a request?

Anyway, the text is very good about explaining the life cycle and that, some time after the servlet has been initialized and has responded to one or more requests, it is destroyed (well, the destroy method is invoked, anyway - whether or not it's actually GC'd is another story). However, the text never explicitly says under what conditions destroy is invoked.

Thanks,
Corey
 
Mary Wallace
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to my minimum knowledge servlet is alive as long as application is alive. If I shut down the webserver, then the servlet is destroyed same as when i redeploy the application.
I can be wrong.
 
Bryan Basham
author
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Corey,

First, the container is started (such as Tomcat) and it creates and initializes any servlets that are deployed within it. Once initialized, a servlet can respond to various requests through execution of the doGet and doPost methods. I believe this information is accurate, but let me know if I've got this wrong.


Not quite. At startup of a webapp, the container will only create/init the servlets that have been marked with a <load-on-startup> tag in the DD. All other servlets (including JSPs) will be created/init on the first HTTP invocation. BTW, JSPs can have a servlet definition and marked for <load-on-startup>.

My question is, when is the destroy() method invoked? I'm guessing that this is invoked when the container is shut down. Or, possibly, is it invoked when the servlet is done processing all active requests. If that's the case, though, then wouldn't the container have to create a new servlet any time a request came in for a servlet that wasn't currently handling a request?


The container is in complete control of the lifecycle of the servlet. It may decide to destroy any servlet at any time, not just at shutdown. The only condition on this is that the container must wait until all current requests for that servlet have been completed (the service method completes execution). And, yes, you are right that once a servlet has been destroyed, then another servlet instance must be created/inited in order to process a new HTTP request (for that servlet).

Anyway, the text is very good about explaining the life cycle and that, some time after the servlet has been initialized and has responded to one or more requests, it is destroyed (well, the destroy method is invoked, anyway - whether or not it's actually GC'd is another story). However, the text never explicitly says under what conditions destroy is invoked.


So, can anyone guess why a container would destroy a servlet?

-Bryan
[ October 21, 2004: Message edited by: Bryan Basham ]
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bryan Basham:
So, can anyone guess why a container would destroy a servlet?


Thanks for your response, Bryan.

The only reason I can think of to destroy a servlet would be to free up memory, in the case that the system was running low. Otherwise, the idea of destroying a servlet seems silly as, when a new request comes in, you'll simply be incurring more overhead to create and init a new servlet.

I'm sure there's some fancy situation when destroying a servlet is perfect (like maybe for a "hot deploy" so that a servlet can be re-inited), but I don't know what one is. Maybe someone else does.

Also, from HFS&J, I found this on page 102, which is where my original assumption came from:


The servlet starts life when the Container finds the servlet class file. This virtually always happens when the Container starts up (for example, when you run Tomcat). When the Container starts, it looks for deployed web apps and then starts searching for servlet class files. (In the Deployment chapter, we'll go into more details of how, why, and where the Container looks for servlets.)


Granted, I haven't yet gotten to the Deployment chapter so maybe all of this will become clear when I do. But, based on what this states and what you said earlier (about servlets being initialized upon their first request), I'm guessing that when servlets are initialized it entirely up to the Container being used and is not standardized from one Container to the next. So, while Tomcat might initialize servlets when it is started, WebSphere might wait until the first request for a servlet to initialize it or it might initialize servlets based on information in the DD.

Does that sound right?

Thanks,
Corey
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

According to my minimum knowledge servlet is alive as long as application is alive. If I shut down the webserver, then the servlet is destroyed same as when i redeploy the application.

Not necessary. The container may create many instances of the same Servlet to handle, say, a sudden increase requests for the same Servlet.

In such sense, at 1st, the container may only want to keep, say, 10 instances, but due to the sudden requests, it creates 10 more.

But then, because such sudden event is just within a short period, there will be 10 *unexpected* Servlet instances kept by the server, and the server may decide to destroy them, since they have low possiblility to be used.

For the original 10 instances, they will be destoryed when the application being ended.

Nick
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The only reason I can think of to destroy a servlet would be to free up memory, in the case that the system was running low

Not necessary, say my previous reply.


I'm guessing that when servlets are initialized it entirely up to the Container being used and is not standardized from one Container to the next. So, while Tomcat might initialize servlets when it is started, WebSphere might wait until the first request for a servlet to initialize it or it might initialize servlets based on information in the DD.

How many instances of a Servlet will be started really depends on how the container handles this issue, which may or may not be under our control, as the specification does not discuss the Servlet management issues.

Nick
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm...I was originally under the impression that there would only be 1 instance of a servlet. When you had multiple requests, you'd simply have multiple threads all executing that servlet code at once.

If there are truly multiple instances of a servlet being used, what are the implications of that to your code? Might you have problems sharing information between requests via servlet instance variables? (Although I'm not sure that's the best way to do it, anyway.)
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If there are truly multiple instances of a servlet being used, what are the implications of that to your code? Might you have problems sharing information between requests via servlet instance variables? (Although I'm not sure that's the best way to do it, anyway.)

So you need to take care on the instance variables. In Servlet 2.3, there is an interface SingleThreadModel, which is a marker interface, to tell the container only 1 request will be served.

But this interface deprecated in 1.4, and thus, I guess this is the responsibility of the developer to cater for multiple requests on the same servlet.

Nick
 
Omar Dziri
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following is pasted from the Servlet spec 2.4, page 139.
----------------------------------------------------------------------
The element load-on-startup indicates that this servlet should be loaded (instantiated and have its init() called) on the startup of the Web application. The element content of this element must be an integer indicating the order in which the servlet should be loaded. If the value is a negative integer, or the element is not present, the container is free to load the servlet whenever it chooses.
----------------------------------------------------------------------

Accordingly, the detail given by Bryan about when a servlet is actually instantiated if it was not deployed with <load-on-startup> element, might not be related to the the first request received.

Feel free to send comments.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic