On Tue, 07 Dec 2004 13:41:06 +0800, Andrew Hill
<[EMAIL PROTECTED]> wrote:
> <snip>
> I would never, of course, dream of grabbing a request object, or
> similar things, and holding it in a new thread. I would never, ever,
> anytime dream of doing that.  Yuk!
> </snip>
> 
> hehe.
> What about the ServletContext object though?
> 

Did you remember to shut down your thread when your app was
undeployed?  If not then the thread's reference you have to a
ServletContext object is likely to be stale.  :-)

On the other hand, I can't remember any guarantees that the object
reference returned by Servlet.getServletContext() is defined to be the
same for all invocations, even through the lifetime of a single app
without considering reloads.

Or, on the other hand, what happens if you are running on a
distributed server, and a particular user session gets migrated from
one server instance to another.  The fact that you might have started
a thread on server instance A doesn't help much when your application
code running on server B tries to queue something up to it.

I tend to be a conservative -- only pass references to objects that
*you* control the lifetime of, such as servlet context attributes,
rather than the ServletContext instance itself.  That way, you can use
the listener APIs provided by your servlet container (2.3 or later) to
clean up threads at appropriate times, without having to hope that
your container isn't

As an incentive to be a good boy or girl in this regard, decoupling
your thread code from the servlet API makes it a lot easier to build
unit tests :-).

Craig

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

Reply via email to