My point is just that "thread local" is typically too low level of an abstraction. Most times, you probably want a higher level abstraction like "request" scope.
The only remaining place I can think of where you might actually want "thread local" scope is for a sort of thread local cache. For example, you might use it for a DateFormat object (which can be reused but only by one thread at a time). If your thread local scope keeps strong references to the values, it won't leak indefinitely (because you have a cap of N threads * M cached items), but it will raise the base memory footprint of your app higher than it needs to be. I've definitely had thread local "leaks" that ran my application out of memory. Perhaps you could tell us more about how you plan to use a thread local scope, but if it's just for thread local caching, maybe you could call it ThreadLocalCacheScope and keep soft references to the values. Bob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
