Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #14857

Re: Proposed new Java feature

From Robert Klemme <shortcutter@googlemail.com>
Newsgroups comp.lang.java.programmer
Subject Re: Proposed new Java feature
Date 2012-05-28 12:13 +0200
Message-ID <a2h1deFoq2U1@mid.individual.net> (permalink)
References <jprnu7$uv8$1@dont-email.me> <a2ehm0Fee8U1@mid.individual.net> <jptqtm$68p$1@dont-email.me>

Show all headers | View raw


On 05/27/2012 08:14 PM, Mike Schilling wrote:
> "Robert Klemme"<shortcutter@googlemail.com>  wrote in message
> news:a2ehm0Fee8U1@mid.individual.net...
>>> 2. ThreadLocals interact badly with ThreadPools, because the ThreadLocals
>>> keep their value when the tyhread is put back into the pool.  This can
>>> lead
>>> to leaks and even potential security issues.
>>
>> I would actually consider this good interaction with thread pools: the
>> local stays around for as long as the thread lives.  If you introduce
>> security issues this way than you are probably not using thread locals
>> properly.  There are two things that you generally need to consider with
>> thread locals which both result from the fact that the life time of a
>> thread local value extends across a current method call (i.e. earlier and
>> later):
>
>
> OK.  Now, coinsider these two cases (for, say, a webserver):
>
> 1. I create a new thread to handle each new request.
> 2. I optimize (1) by using a thread pool to minimize thread creation.
>
> I want those two to behave identically (other than performance). To acheive
> that, I need to be able to kill all the ThreadLocals when putting the
> Threads back into the pool for later reuse.  Otherwise

No, you don't.  If you employ proper cache size management schemes (e.g. 
via a LRU) then you do not get rid of the ThreadLocal after each 
request.  If for any reason this is not possible and you want to get rid 
of state after the request then it should be done per individual 
ThreadLocal and not globally for all ThreadLocals.

> A. The ThreadLocals for threads in the pool cause packratting.

Then you do not employ proper cache size management.  You always need to 
be aware of the life time difference between a method call and a 
ThreadLocal and code appropriately.  Not doing this is not following the 
contract of ThreadLocal.

> B. A reused thread contains context created during its previous use.  This
> may be context that the user correspnding to the request currently being
> handled by the thread should not be able to see.

Then you are not using ThreadLocal properly, i.e. have omitted proper 
cleanup (e.g. because you either did not do it or did not do it in a 
safe way, i.e. finally block).

Kind regards

	robert

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-26 16:11 -0700
  Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-27 13:32 +0200
    Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 11:14 -0700
      Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:13 +0200
      Re: Proposed new Java feature v_borchert@despammed.com (Volker Borchert) - 2012-06-04 20:16 +0000
  Re: Proposed new Java feature markspace <-@.> - 2012-05-27 09:28 -0700
    Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 11:00 -0700
      Re: Proposed new Java feature Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-27 11:46 -0700
        Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 12:04 -0700
          Re: Proposed new Java feature Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-27 15:30 -0400
            Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 12:59 -0700
              Re: Proposed new Java feature Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-27 17:51 -0400
                Re: Proposed new Java feature markspace <-@.> - 2012-05-27 15:20 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:13 +0200
                Re: Proposed new Java feature markspace <-@.> - 2012-05-28 08:28 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 19:29 +0200
                Re: Proposed new Java feature markspace <-@.> - 2012-05-28 12:16 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 22:58 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-28 21:40 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-29 22:52 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-29 18:53 -0700
                Re: Proposed new Java feature Tom Anderson <twic@urchin.earth.li> - 2012-05-27 23:27 +0100
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:22 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 21:43 -0700
                Re: Proposed new Java feature Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-05-29 14:32 +0000
  Re: Proposed new Java feature Tom Anderson <twic@urchin.earth.li> - 2012-05-27 18:43 +0100
  Re: Proposed new Java feature Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-02 12:41 -0700
    Re: Proposed new Java feature markspace <-@.> - 2012-06-02 15:55 -0700

csiph-web