springframework-developer

[Springframework-developer] Article on not using ThreadLocal

[Tim K. <tim...@vi...>]

This guy (presumably a senior dev @ IBM) says not to use ThreadLocal.  He
says that usage should be removed from open-source projects (mentioning
Spring specifically).

 

Wanted to pass this url on - see what you Spring developers thought about
this.

 

http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html

Re: [Springframework-developer] Article on not using ThreadLocal

[John W. <jkw...@gm...>]

VGhlIHJlYWwgcXVlc3Rpb24gKElNSE8pIGlzIHdoeSB0aHJlYWQtcG9vbCB2ZW5kb3JzIGRvbid0
IGNsZWFyIHRocmVhZApsb2NhbHMhICBJIGRvIGFncmVlIHRoYXQgaXQgY2FuIGJlIHZlcnkgZGFu
Z2Vyb3VzIHRvIHVzZSB0aGUKVGhyZWFkTG9jYWwuICBZb3UgZG8gbmVlZCB0byBrbm93IHdoYXQg
eW91J3JlIGRvaW5nIHdoZW4geW91IHVzZSB0aGVtLgogSSB3aXNoIHRoYXQgdmVuZG9ycyB3b3Vs
ZCBoZWxwIHByb3RlY3QgdXMgZnJvbSBvdXIgb3duIHNsb3BwaW5lc3MsCnRob3VnaC4KCkpvaG4K
CgpPbiA2LzE1LzA1LCBUaW0gS2V0dGVyaW5nIDx0aW0ua2V0dGVyaW5nQHZpdmFrb3MuY29tPiB3
cm90ZToKPiAgCj4gIAo+IAo+IFRoaXMgZ3V5IChwcmVzdW1hYmx5IGEgc2VuaW9yIGRldiBAIElC
TSkgc2F5cyBub3QgdG8gdXNlIFRocmVhZExvY2FsLiAgSGUKPiBzYXlzIHRoYXQgdXNhZ2Ugc2hv
dWxkIGJlIHJlbW92ZWQgZnJvbSBvcGVuLXNvdXJjZSBwcm9qZWN0cyAobWVudGlvbmluZwo+IFNw
cmluZyBzcGVjaWZpY2FsbHkpLiAKPiAKPiAgIAo+IAo+IFdhbnRlZCB0byBwYXNzIHRoaXMgdXJs
IG9uIJYgc2VlIHdoYXQgeW91IFNwcmluZyBkZXZlbG9wZXJzIHRob3VnaHQgYWJvdXQKPiB0aGlz
hSAKPiAKPiAgIAo+IAo+IGh0dHA6Ly93d3cuZGV2d2Vic3BoZXJlLmNvbS9kZXZ3ZWJzcGhlcmUv
MjAwNS8wNi9kb250X3VzZV90aHJlYWQuaHRtbAo=

Re: [Springframework-developer] Article on not using ThreadLocal

[Juergen H. <ju...@in...>]

Quoting myself from my reply to Billy's post:

Actually, Spring does not use ThreadLocals in the way you describe. Spring
always just uses ThreadLocals temporarily, while guaranteed to be on the
same thread, with proper cleanup at the end (in any case). This applies to
transaction ThreadLocals as well as to others.

IMO, this is completely valid: As long as the ThreadLocal is always
guaranteed to be cleaned up when returning the thread to the server's pool,
I cannot see anything going wrong... So it's not about using ThreadLocals in
general, it's about _properly_ using ThreadLocals.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of John Watson
Sent: Wednesday, June 15, 2005 10:24 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Article on not using
ThreadLocal


The real question (IMHO) is why thread-pool vendors don't clear thread
locals!  I do agree that it can be very dangerous to use the
ThreadLocal.  You do need to know what you're doing when you use them.
 I wish that vendors would help protect us from our own sloppiness,
though.

John


On 6/15/05, Tim Kettering <tim...@vi...> wrote:
>
>
>
> This guy (presumably a senior dev @ IBM) says not to use ThreadLocal.  He
> says that usage should be removed from open-source projects (mentioning
> Spring specifically).
>
>
>
> Wanted to pass this url on – see what you Spring developers thought about
> this…
>
>
>
> http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html
HSµéŠX²š²Šu¼ŠÇ½êjÌŠ{2(jØ+j׉뮉ÁÛš™¶‡–ZF†™ª²ÚŠ~Šj·®Ø•ëú™«½åmƶÆvjxgz÷ÊØ
žºwvÚzÛ¶‹yçj˶Úý§¢Çr‰iØ¾í©¡È^÷j
ÉrD®)~¶{
‘×zZz¹ŠX‚Xµ*Šx­©ÂŠuë–Š®X¶Ëº·~Šzw†Û³ÿŠË²‹qç®zߊËþX¶)£û®)~¶{
‘×zZ

Re: [Springframework-developer] Article on not using ThreadLocal

[Dain S. <da...@iq...>]

On Jun 15, 2005, at 1:23 PM, John Watson wrote:

> The real question (IMHO) is why thread-pool vendors don't clear  
> threadlocals!  I do agree that it can be very dangerous to use  
> theThreadLocal.  You do need to know what you're doing when you use  
> them. I wish that vendors would help protect us from our own  
> sloppiness,though.

 From what I heard, Websphere used to do exactly that (you just use  
setAccesable and clear the hashmap).  The problem was that way too  
much of their customer's code depended on thread locals not being  
cleared.  Customers were doing dumb stuff like using it for a cache  
between requests.

Anyway, I agree with Juergen; the problem is improper use of thread  
locals.  I just recently fixed a bunch of memory leaks in Geronimo do  
to poor thread local handling.  BTW a related issue is clearing the  
context class loader as it can cause class loaders to not be garbage  
collected.  Basically any thread state needs to be carefully managed  
since they are GC roots.

-dain

Re: [Springframework-developer] Article on not using ThreadLocal

[Andy D. <an...@ma...>]

Many times ThreadLocal is used to maintain information concerning the current 
call stack, with that information being discarded as the stack unwinds.  The 
basic idea is effectively like this:

  ((SomeStack)threadLocal.get()).push(info);
  try {
    ...
  } finally {
    ((SomeStack)threadLocal.get()).pop();
    ... code to clean up threadLocal if empty stack ...
  }

ThreadLocals come in handy when you want code in a particular call stack to 
have access to context information that can't be passed around as parameters.  
Transactions, security, auditing, etc, are all examples of things that often 
utilize ThreadLocals for the duration of a single "call stack".  In my mind, 
this particular pattern should be resilient to the effect described in the 
blog.  The pattern looks something like this (pseudo flow):

1. Request comes in from client
2. J2EE container pulls a thread from the pool to handle request
3. J2EE container eventually invokes Spring based code which happens to use 
Spring for transaction management.
4. Spring sets up transaction context in a ThreadLocal.
5. Spring based code invokes various service beans (which in turn can invoke 
other service beans), utilizing the ThreadLocal transaction context for 
transaction management.
6. Spring based code finishes, Spring cleans up ThreadLocal and returns to the 
J2EE Container.
7. J2EE Container puts thread back in pool, possibly wiping ThreadLocals.

The one thing developers need to be careful of in this usage pattern is 
properly cleaning up ThreadLocals (for security reasons) before returning 
control to the J2EE container.

Where I see a problem is if any code expects ThreadLocal to survive between 
client requests (if using the above example).  The only other problem would 
be if Spring code happens to invoke some interface that jumps threads:
  a. Spring code invokes EJB interface
  b. Container decides to handle invocation in another thread.
  c. Spring code is blocked while other thread handles invocation.
     - This other thread has no access to ThreadLocal contextual information 
from calling thread.
  d. Other thread finishes.
  e. Container wakes up original thread, passing in the return value.
As silly as this seems, it can happen in practice depending on the 
architecture of the system.

As long as Spring sticks to this usage pattern, then I'm not seeing a problem 
- or am I missing something?

  - Andy


On Wednesday 15 June 2005 01:01 pm, Tim Kettering wrote:
> This guy (presumably a senior dev @ IBM) says not to use ThreadLocal.  He
> says that usage should be removed from open-source projects (mentioning
> Spring specifically).
>
>
>
> Wanted to pass this url on - see what you Spring developers thought about
> this.
>
>
>
> http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html