Thanks again.
On Tue, 21 Jan 2003, Shapira, Yoav wrote:
> No. Destroy() on the servlet is guaranteed to be called when the
> servlet specification says it should be called. Same thing goes for the
> servlet context listener's contextDestroyed() event. Tomcat could
> legally decide to swap out your servlet while some of the threads you
> spawned from it are still executing. Or someone could recycle the
> server as part of normal (nightly/weekely/whatever) operating procedure.
> In that case, destroy() would get called while your threads are still
> executing, and you'll end up in the bad state described in my previous
> message.
>
I appreciate that the container may want to swap my instance out at
unpredictable intervals, but I'm still unclear on the relation between
the threads and the call to destroy. I'm reading the spec--"Before the
servlet container calls the destroy method, it must allow any threads that
are currently running in the service method of the servlet to complete
execution, or exceed a server defined time limit"--as:
1. Container decides to unload the instance
2. If no spawned threads executing
Just call the instance's destroy()
3. Else
Wait for threads to exit (or timeout, depending on container
policy)
Then call destroy()
...but you're saying it's really:
1. Container decides to unload the instance
2. Container calls destroy() on the instance
3. Any pending threads run to completion.
Yes?
Thanks, Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
