Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #14857
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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