[concurrency-interest] reusing threads and thread local state
gregg at cytetech.com
Thu May 5 12:34:34 EDT 2005
Mike Skells wrote:
> The point is that the approach that you propose is not suitable for the
> general case.
> 1. It doesn't work in J2EE
> 2. It doesn't work when you are writing reusable code (ie not the app)
> 3. It stops the application being swapped
> Given the above it does not seen to be a good idea to post is as the
> solution to the problem that was described.
The whole world is not J2EE powered. The fact that J2EE isolates you
from some of the capabilities of the J2SE platform is a completely
different issue. Regarding #2, I don't think I provided any concrete
code that what I wrote which showed that I was not creating reusable
code. If you interpreted it that way, I'm sorry for confusing you. I
do create reusable code where that makes sense. In some cases it's not,
because the application has some very specific needs.
I'm not sure what #3 refers to. The application is J2SE compatible and
can thus be run on any J2SE complient JVM.
> BTW WeakHashMap is _not_ a same management mechanism for the problem below.
> You are assuming that there in no reference to the Thread in any of the
> values that you maintain, or anywhere else in any system you ever write.
> This is precisely the problem that causes memory leaks
I didn't suggest WeakHashMap as a 'same management mechanism'.
WeakHashMap is a useful mechanism only where the key can not be
referenced by external, uncontrolled sources. Global objects, such as
Thread are in fact, poor choices. The mechanism that I posted about in
an earlier note uses a separate object as the key. This eliminates the
global data view conflict as long as accessibility to that object is
More information about the Concurrency-interest