tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chema <>
Subject Re: Babysitting ThreadLocals
Date Wed, 23 Nov 2011 16:31:00 GMT
A silly question:

why do you use a ThreadLocal to store a constant value for entire
application? why not a static variable or store into web application
context , by example ?


2011/11/23 Christopher Schultz <>:
> Hash: SHA1
> All,
> I've got a servlet that needs to log every request (potentially big
> requests) to files on the disk. In order to do that in a
> reasonably-tidy way, we write each file into a directory with the
> current date in the path, something like this:
> .../logs/2011-11-23/request-XYX.log
> To do this, we have a SimpleDateFormat object that we use to ensure we
> target the right directory. Since SimpleDateFormat isn't threadsafe,
> we have two choices: synchronize or use ThreadLocal. We have opted for
> the latter: ThreadLocal.
> Our servlet defines the ThreadLocal to be protected (because this is a
> base class for several servlets that all do similar things) and
> transient (because we just don't need it to be serialized) and
> override the initialValue method, like this:
>    protected transient ThreadLocal<SimpleDateFormat> dayFormat = new
> ThreadLocal<SimpleDateFormat>() {
>        public SimpleDateFormat initialValue()
>        {
>            return new SimpleDateFormat("yyyy-MM-dd");
>        }
>    };
> In the servlet's destroy method, we dutifully call dayFormat.remove().
> Tomcat complains that we are leaving sloppy ThreadLocals around on
> shutdown. Duh: Servlet.destroy is called by a single thread and won't
> actually remove the ThreadLocal in any meaningful way.
> So, my question is whether or not there is a good way to clean-out the
> ThreadLocals from our webapp?
> Given the declaration above, we are creating a new class which will be
> loaded by our webapp's ClassLoader and therefore pinning that
> ClassLoader in memory definitely causing a memory leak across reploy
> cycles.
> One way to avoid this would be to have a library at the server-level
> that only contains this simple ThreadLocat<SimpleDateFormat>
> definition, but that seems like kind of an awkward solution.
> Removing the ThreadLocal after every request of course means that the
> use of ThreadLocal is entirely useless.
> Should I stop worrying about the overhead of creating a
> SimpleDateFormat? Should I look for a threadsafe implementation of
> SimpleDateFormat (maybe in commons-lang or something)? Should I
> synchronize access to the object?
> Any suggestions would be very helpful.
> Thanks,
> - -chris
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Mozilla -
> SpYAoJQ6dcxCi4WmPX+1BJs9b3c+UQB5
> =3bj2
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message