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
[13:53:01 EDT(-0400)] <esm> oh i see two different locks
[13:53:07 EDT(-0400)] <esm> hnm
[13:53:44 EDT(-0400)] <EricDalquist> true, you either need to re-read relevant data from the concurrent structure after obtaining the writelock or just make your write lock broad enough to not worry about the structure changing between the read and necessary write
[13:53:51 EDT(-0400)] <EricDalquist> but for things like a Map
[13:54:01 EDT(-0400)] <EricDalquist> the majority of interaction is most cases is a get()
[13:54:13 EDT(-0400)] <EricDalquist> those can all just aquire a read lock
[13:54:57 EDT(-0400)] <EricDalquist> take a peak at ConcurrentHashMap
[13:55:05 EDT(-0400)] <EricDalquist> very handy in JDK5+ coding
[13:59:16 EDT(-0400)] <EricDalquist> its fun watching the start of each class period via gl_tail
[13:59:31 EDT(-0400)] * agherna (n=argherna@cites-agherna01.ci.uiuc.edu) has joined ##uportal
[14:04:57 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[14:22:34 EDT(-0400)] <esm> check-(lock)-then-read is definitly bad
[14:22:41 EDT(-0400)] <esm> i'll take a look CHM
[14:22:53 EDT(-0400)] <EricDalquist> CHM is actually really interesting
[14:23:03 EDT(-0400)] <esm> I have no doubt!
[14:23:16 EDT(-0400)] <esm> concurrency in practice is a pretty good book so far
[14:23:21 EDT(-0400)] <EricDalquist> it is designed such that there is less locking than if written with straight R/W locking
[14:23:25 EDT(-0400)] <esm> cool
[14:23:27 EDT(-0400)] <EricDalquist> good to know
[14:23:32 EDT(-0400)] <EricDalquist> I'll have to find it
[14:37:07 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[15:25:43 EDT(-0400)] <EricDalquist> I suppose I should create a working- branch for doing the pluto work
[15:25:49 EDT(-0400)] <EricDalquist> since it will break things for a while
[15:40:14 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[17:08:22 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-68-186.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[17:17:39 EDT(-0400)] * clown (n=chatzill@guiseppi.atrc.utoronto.ca) has left ##uportal
[17:18:24 EDT(-0400)] * anastasiac (n=anastasi@142.150.154.154) has left ##uportal
[19:57:03 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-68-186.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[21:02:20 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-86-115.nwrknj.east.verizon.net) has joined ##uportal
[21:17:17 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-86-115.nwrknj.east.verizon.net) has joined ##uportal