tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Rosenberg <rosenberg.l...@gmail.com>
Subject Re: Question on Thread Local
Date Tue, 02 Sep 2014 20:53:43 GMT
no :-)
Allow me to provide an example.
This class : MoSKitoWebUIContext.java (
https://github.com/anotheria/moskito/blob/master/moskito-webui/src/main/java/net/anotheria/moskito/webui/MoSKitoWebUIContext.java
)
Is a ThreadLocal that is used to store some information, for example
HttpSession.
In the beginning of the processing I am calling
MoSKitoWebUIContext.getCallContextAndReset(); //that initializes the
context and than
MoSKitoWebUIContext .getCallContext().setCurrentSession(HttpSession
currentSession);

from this time on the link to current session is stored in the ThreadLocal
variable, and whereever in the call I need it, I can simply call
MoSKitoWebUIContext .getCallContext().getCurrentSession() and obtain it,
without explicitly passing it through call trees. This allows me to pass
parameters from a very beginning of the processing to the very end of the
processing (or just everywhere) without passing them around and having them
in each and every method.

Another popular example would be to store the Locale the user is in for
i18n.

HTH
Leon


P.S. of course you need to clean up the thread locals at the end of
processing (at least in theory) and so on.


On Tue, Sep 2, 2014 at 10:22 PM, Leo Donahue <donahulf2@gmail.com> wrote:

> On Tue, Sep 2, 2014 at 3:00 PM, Leon Rosenberg <rosenberg.leon@gmail.com>
> wrote:
>
> > From practical point of view ThreadLocal is a huge hashmap directly in
> the
> > ThreadClass where you can store a map of variables.
> > Something like Thread.Map<ThreadId, Map<String, Object>>, in which you
> can
> > access variables that are 'attached' logically to the current Thread.
> > In practice its a nice way to pass information through layers of code
> > without adding it explicitly as parameter to every function on the way.
> > regards
> > Leon
> >
>
> At some point in the web application, a ThreadLocal is instantiated and its
> properties are set and then retrieved in a Filter.  Am I on track here?
>
> How is that different or more helpful than instantiating any other POJO
> with property setters?
>
> A POJO will be instantiated on every servlet request whereas the
> ThreadLocal is only created once?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message