Whooops. I had read the following: RE>> (This article also states that ThreadLocal works even slower RE>> before JDK 1.4)
as "This article also states that ThreadLocal works even slower [than] before [in] JDK 1.4". So, I thought you were saying that the implementation of ThreadLocal was slower in j2sdk1.4.0 than in 1.3.1. I accepted that idea because I know of a number of performance regression fixes between j2sdk1.4.0 and j2sdk1.4.1. Well, either way, I use j2sdk1.4.1 which should be even faster than 1.4.0 and if the author thinks that 1.4.0 has performance gains over the alternative of running through the syncronized block every time, then it looks like I am doing the most optimized thing I can do by using ThreadLocal. Now, the only other consideration is whether I want to be able to modify the configuration of the DataSource at runtime using the Tomcat Admin app. If that is the case, then I'd throw out all the synchronization stuff and just use query the InitialContext every time for the DataSource object. Craig seemed to think that solution would be pretty fast and provide flexibility. I will definitely consider it. Jake Tuesday, October 29, 2002, 11:49:23 AM, you wrote: JK> Hello Ralph, JK> Well, supposedly, everything slowed down in the j2sdk1.4.0 release. JK> The j2sdk1.4.1 release fixed a *ton* of performance regressions that JK> occurred between jdk1.3.x and j2sdk1.4.0. So, I think the jury is JK> still out on whether ThreadLocal is still slow in j2sdk1.4.1. JK> And yes, the goal is to reduce synchronized access to improve JK> performance. If I do remove the outer if using the old way that I had JK> things set up, wouldn't that now make it so I *do* incur the JK> excessive synchronization performance hit? ThreadLocal, if it works JK> speedily in j2sdk1.4.1, should solve that, should it not? JK> Jake JK> Tuesday, October 29, 2002, 2:40:16 AM, you wrote: RE>> The best way to avoid the double checke locking issue RE>> is just not to use it. RE>> Before trying to implement 'double checked locking' right, RE>> you have to understand the purpose. RE>> The goal was to reduce synchronized access to achieve more RE>> performance. (Did you have another rationale ?) RE>> In most cases it's just enough to remove the outer if. RE>> Also look at: RE>> http://www.javaworld.com/javaworld/jw-11-2001/jw-1116-dcl.html RE>> (This article also states that ThreadLocal works even slower RE>> before JDK 1.4) >>> -----Original Message----- >>> From: Jacob Kjome [mailto:hoju@;visi.com] >>> Sent: Tuesday, October 29, 2002 5:12 AM >>> To: Tomcat Users List >>> Cc: Craig R. McClanahan >>> Subject: Re[2]: DBCP speed of lookup -vs- stored reference to >>> Datasource? >>> >>> I was just making an attempt to avoid the >>> Double-Checked Locking issue and the article >>> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html >>> under the title "Fixing Double-Checked Locking >>> using Thread Local Storage" provided an issue >>> that they said worked. Maybe you could provide >>> an example showing me what you would do to create >>> a proper static singleton that doesn't suffer >>> from the Double-Checked Locking issue without >>> resorting to the ThreadLocal solution? >>> RE>> -- RE>> To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> RE>> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> -- Best regards, Jacob mailto:hoju@;visi.com -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
