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]