Page Comparison

[08:47:57 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[09:31:19 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:28:27 EDT(-0400)] * anastasiac (n=anastasi@142.150.154.154) has joined ##uportal
[11:00:04 EDT(-0400)] * michelled (n=michelle@142.150.154.114) has joined ##uportal
[11:10:25 EDT(-0400)] * clown (n=chatzill@guiseppi.atrc.utoronto.ca) has joined ##uportal
[11:16:51 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[11:17:02 EDT(-0400)] <pberry> EricDalquist: no, I have yet to figure out this tomcat thing
[11:17:14 EDT(-0400)] <EricDalquist> :/
[11:17:52 EDT(-0400)] <pberry> yeah
[11:20:57 EDT(-0400)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal
[12:03:18 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[13:23:43 EDT(-0400)] * colinclar1 (n=atrcwrk2@142.150.154.101) has joined ##uportal
[13:40:12 EDT(-0400)] <pberry> http://www.jroller.com/Solomon/entry/spring_2_5_perfomance_improvements
[13:40:27 EDT(-0400)] <pberry> 200% improvement in concurrent access?
[13:40:32 EDT(-0400)] <pberry> that seems like a bold statement
[13:41:07 EDT(-0400)] <EricDalquist> I'm not supprised
[13:41:13 EDT(-0400)] <EricDalquist> "You get this performance improvements out-of-the-box if you use JDK 5.0+ or if you add the Emory concurrent utilities backport to your classpath."
[13:41:25 EDT(-0400)] <EricDalquist> switching from generic synchronization to using Locks is HUGE
[13:42:03 EDT(-0400)] <EricDalquist> especially since I'm betting much of Spring's syncing could be re-written using Read/Write locking versus a static synchronized block
[13:42:31 EDT(-0400)] <EricDalquist> commons-pool (and things that use it like DBCP) are a great example
[13:42:54 EDT(-0400)] <EricDalquist> since that code runs on JDK1.3+ it just uses synchronized() to make it threadsafe
[13:43:13 EDT(-0400)] <EricDalquist> problem is it has to synchronize on every check out and check in
[13:43:22 EDT(-0400)] <pberry> oy
[13:43:35 EDT(-0400)] <EricDalquist> using read/write locking you could only aquire read locks for the majority of that work
[13:44:05 EDT(-0400)] <EricDalquist> and upgrade them to write locks when you actually need to modify the synchronized data
[13:44:38 EDT(-0400)] <EricDalquist> that was the big secret with moving from JDK1.4 / tomcat 5.0 to JDK 1.5 & tomcat 5.5
[13:45:05 EDT(-0400)] <EricDalquist> core bits of tomcat were updated to use the new concurrency APIs
[13:45:18 EDT(-0400)] <pberry> ah
[13:45:20 EDT(-0400)] <EricDalquist> granted it is much easier to break things with those APIs
[13:45:34 EDT(-0400)] <EricDalquist> like you better make sure you unlock in a finally block and such
[13:45:56 EDT(-0400)] <EricDalquist> but having JVM supported locks and mutexes can make a huge difference
[13:46:14 EDT(-0400)] <EricDalquist> that is the main reason I can't wait for JDK1.4 and below to just go away
[13:48:31 EDT(-0400)] <pberry> makes sense
[13:51:59 EDT(-0400)] <esm> concurrency in practice argues that you can't just lock on write
[13:52:25 EDT(-0400)] <esm> i forget their argument though