The clear point for me is that thread locals must be set and cleared in the context they are used. If you had a mechanism that allowed you to "clear" all of the thread locals in a given thread, how does this change the fact that the next thread still has to establish the call context? You can't differentiate the cleared state from a left over value from a previous thread if it happens to be the same as the cleared state.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 16, 2003 1:35 PM Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken > I think his point was that all of the threads in the pool being used > will become polluted with whatever crap this framework put into its > thread local. At least that's what annoys me when frameworks use > threadlocal stuff (IIRC, ObjectStore did this to me at one point) > > -danch ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
