See below.

On Tue, 21 Jan 2003, Mark Francillon wrote:

> Date: Tue, 21 Jan 2003 10:37:39 -0500 (EST)
> From: Mark Francillon <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: RE: lifetime of servlet instance and of instance-spawned threads
>
>
> 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()

The container has no way to know that there are any threads spawned by the
application -- that's the application's problem.

>   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

After ensuring that there are no requests currently using that instance.

>   3. Any pending threads run to completion.

If you want to wait for app threads to finish, wait for them in the
destroy() method itself.

>
> Yes?
>
> Thanks, Mark
>

Craig


>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to