As far as I know, ThreadLocal is rather efficient way to keep track of stuff like per-request context, or in general thing that has easily trackable life cycle. Just make sure that they do get cleaned up, or use soft/weak references for things like cached/recycled objects.
The problems we have had have occured when there are massive number of long-living resources and reasonably high number of concurrent threads reused using a threadpool. In those situations the actual backing ThreadLocalMaps (stored in Thread) can grow to huge sizes, even if ThreadLocal data is cleaned up properly; essentially worst case memory retention because cartesian product.
But I don't think this would happen with Jersey: use case I am familiar with caused problems because some java.util.concurrent.lock.* locks actually use ThreadLocals under the hood.
-+ Tatu +-
--- On Tue, 10/21/08, Paul Sandoz <Paul.Sandoz_at_Sun.COM> wrote:
> From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> Subject: [Jersey] Simplification of Injectable by using ThreadLocal
> To: users_at_jersey.dev.java.net
> Date: Tuesday, October 21, 2008, 4:57 AM
> Hi,
>
> The Injectable interface is as follows:
>
> public interface Injectable<T> {
> T getValue(HttpContext context);
> }
>
> it pulls in HttpContext thus a whole bunch of other stuff
> in the
> jersey-core that is not really required.
>
> It would be better if it was like this:
>
> public interface Injectable<T> {
> T getValue();
> }
>
> But this requires that per-request based injectable
> providers, like
> for @QueryParam have access to and use the
> ThreadLocal<HttpContext>
> instance, instead of accessing the HttpContext instance
> passed to the
> getValue method.
>
> Is this a performance concern i should be worried about?
> Anyone else
> have any experience with ThreadLocal?
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail:
> users-help_at_jersey.dev.java.net