Hello Ralph, Well, supposedly, everything slowed down in the j2sdk1.4.0 release. The j2sdk1.4.1 release fixed a *ton* of performance regressions that occurred between jdk1.3.x and j2sdk1.4.0. So, I think the jury is still out on whether ThreadLocal is still slow in j2sdk1.4.1.
And yes, the goal is to reduce synchronized access to improve performance. If I do remove the outer if using the old way that I had things set up, wouldn't that now make it so I *do* incur the excessive synchronization performance hit? ThreadLocal, if it works speedily in j2sdk1.4.1, should solve that, should it not? Jake 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>
