Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Proposed new Java feature Date: Mon, 28 May 2012 12:22:28 +0200 Lines: 57 Message-ID: References: <8Euwr.47425$On2.20024@newsfe16.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net BXvLd23/NDoRlHSPiUys1Qe6HUoLh2Un9rvkGyr+sPVqAHefod/eWNPoAf8Tgqu2s= Cancel-Lock: sha1:E9LEcY+j+zkwkcaxIPWnKwc0IAU= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:14859 On 05/28/2012 12:27 AM, Tom Anderson wrote: > On Sun, 27 May 2012, Eric Sosman wrote: > >> If you think of anything new to add, pray do so. > > Mike added this pithy statement of the goal: > > Or, to say it another way, when getting a Thread from a ThreadPool, it > should be completely indistinguishable whether it's a recycled or > brand-new thread. > > At the moment, it is *not* possible to achieve that, because > ThreadLocals will survive recycling. But that is actually a good thing: ThreadLocal's purpose is to attach state to a thread which can be accessed without synchronization (if not shared). Consider attaching a database connection to a thread. It would be disastrous for the connection itself to just clear the object reference through some global "remove all" and you would pay a high price for opening new connections over and over again. If the database connection is supposed to be attached to a thread for only a certain amount of time (e.g. a method call) then it must be coded to be properly cleaned up; in case of a JDCB connection that means invoking commit() or rollback() and then close(). Only after that you can safely clear the reference. But this entirely depends on the ThreadLocal at hand and needs to be done specifically for individual ThreadLocals - it cannot be done globally. > One way of looking at a thread pool is that it provides a supply of > fresh short-lived virtual threads, implemented on top of long-lived real > threads. Every time we take a thread out of the pool, we want it to > appear brand-new. Deleting all ThreadLocals when a real thread is > recycled is not "extremely dangerous", because at that moment, the > *virtual* thread is dying, and a new one is being created; that makes it > an entirely appropriate thing to do. It *is* dangerous as I have explained above. The observable state of each of these virtual threads should of course be identical but that does not mean that the technical state must be identical (that's basically what caching is all about). For example, in case of the DB connection you might open the connection in initialValue() or some other logic so the code using the ThreadLocal always sees a properly initialized connection. > It is certainly true that it is "only a crutch for not doing the right > thing to begin with", but the sad fact is that programmers persist in > not doing the right thing to begin with, and it is useful for framework > writers to be able to limit the damage they can cause. Actually the global remove would cause more damage than it prevents. You cannot know about all the other ThreadLocals used in code and a framework writer who attempts to just clear state of other modules without even knowing them should be tarred and feathered. Cheers robert