On Tue, Aug 4, 2009 at 11:16 AM, Paul Lindner <[email protected]> wrote:
> > I've been looking into Reqest Scopes and GuiceFilter and noticed that > it uses a ThreadLocal to store the request state. This works fine for > single threaded request/response model. However if an application > uses a cached thread pool or child threads then injection is not > possible. You mean asynchronous request processing? This isn't really within the HTTP request scope though =( > > Is there a solution in the works for this situation? An > InheritableThreadLocal would suffice for threads created by the > request thread -- however using something like > Executors.newCachedThreadPool(); would not. > The issue here is encapsulating your worker scope inside the relevant HTTP request. I would suggest a lookup boundary that identifies the request using some kind of processing token that can be passed to the worker pool. In fact we do exactly this in one of our major apps at Google. I'm not particularly fond of keeping state around in thread locals, unfortunately this is a hack we have to live with given the servlet programming model... Jesse also has some experience in this area, he might have different thoughts. Dhanji. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
