3

Is it a good idea to use ThreadLocal as a context for data in web application?

BenMorel
  • 34,448
  • 50
  • 182
  • 322
  • Why dont use the SessionContext provided by the framework? – Marcos Vasconcelos Feb 01 '11 at 17:43
  • @Marcos, are you saying that SessionContext is provided by Java? Sorry did n't get which framework you are referring to... – peakit Feb 01 '11 at 17:46
  • I think he was referring to the HttpSession and/or the ServletContext (application scoped). – jhouse Feb 01 '11 at 17:47
  • @Marcos: I think you're referring to `javax.ejb.SessionContext`. What if the application isn't using Enterprise JavaBeans? – Dan Breslau Feb 01 '11 at 17:47
  • This WebApplication mean an Web site or an Desktop Application with web access? If you are using JSP you can get the SessionContext from the request parameter. – Marcos Vasconcelos Feb 01 '11 at 17:48
  • The only possible answer to this question is "sometimes." What do you actually want to keep in the thread local? – Affe Feb 01 '11 at 17:49
  • 1
    `SessionContext` is something very different, especially it is *not* limited to a single Thread (consider AJAX). In some situations it is what's needed, in others the `RequestContext` is more appropriate. – maaartinus Mar 08 '11 at 04:01

5 Answers5

6

That's what it was made for. But take care to remove the ThreadLocal on the end of the context, else you might run in memory leaks, or at least hold unused data for too long.

ThreadLocals are also very fast, you can think of it as a HashMap<Thread,Object>, which is always queried with Thread.getCurrentThread().

Daniel
  • 27,718
  • 20
  • 89
  • 133
6

That depends on the scope of the data. The ThreadLocal will be specific to the request thread, not specific to the user's session (each request, a different request processing thread may be used). Hence it will be important to remove the data as the request processing is completing (so that it doesn't bleed over into some other user's session when that same thread services their request).

jhouse
  • 2,674
  • 1
  • 18
  • 17
2

If you are completing a request/response pair with a single thread, then it works fine in my experience. However, "event driven" webapps are coming into vogue with the rise of ajax and high performance containers. These event driven models allow for a request thread to be returned to their thread pool, e.g. during I/O events, so that the thread is not occupied waiting for an external service call to return. As a result, a single logical request may be serviced by multiple different threads. Event driven architecture, coupled with NIO on the server side can yield highly improved throughput.

With that said, if your application doesn't have this architecture, it seems reasonable to me.

If you're not familiar with this model, take a look at Tomcat 6's "comet" and Jetty 6's Continuations. These are vendor-specific implementations of asynchronous I/O pending official Servlet 3.0 support. Note that Tomcat 7 claims to be fully 3.0 compliant now.

Joe Hanink
  • 4,767
  • 4
  • 19
  • 21
  • 1
    it doesn't actually have to be "event driven". WebSphere 7+ will reuse your threads if they are idle (waiting for IO), and you can then have one thread working on two different requests. I've seen this in action with work being 'multiplexed' between the two requests. This will result in a really ugly bug if you use threadlocals. – Renan Jul 01 '15 at 03:05
2

ThreadLocal in a multithreaded program is much the same as a static/global in a non-threaded program. That is to say, use of ThreadLocal is an abomination.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
  • No, it is a nice way to pass context information deep down the function call hierarchy without having to use parameters. – Daniel Feb 01 '11 at 19:19
  • 4
    @Daniel Yeah, exactly like a static/global in a single-threaded program. – Tom Hawtin - tackline Feb 01 '11 at 19:20
  • `ThreadLocal` is a good choice if you are running your own session handling. Most web frameworks will do that for you and might offer more flexibility (like switching to NIO-based worker threads, where sessions are switched between threads) – Jochen Bedersdorfer Feb 01 '11 at 19:59
1

In general I would say no. Use frameworks to do that for you.

In the web-tier of a web application use the session context (or other on top framework specific contexts) to store data and state over request scope.

If you introduce a business layer it should not be dependent on a specific web-context of course. spring and Java EE provide solutions for security, transactions and persistence as a context.

If you touch this manually you should be really careful; it can lead to cleanup problems, memory leaks, and strange bugs...

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
cschaefer
  • 1,654
  • 2
  • 12
  • 10