click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Malcolm Edgar (JIRA)" <>
Subject [jira] Commented: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with java.util.concurrent.ConcurrentHashMap
Date Wed, 03 Mar 2010 22:38:27 GMT


Malcolm Edgar commented on CLK-636:

Hi Henry,

The difficulty in applying this change is that I am not confident that it will not reintroduce
the Spring errors we observed earlier.  This error is difficult to quantify, does it only
occur with certain Spring versions, with certain configurations and application JAR dependencies,
does it relate the application server etc.

regards Malcolm Edgar

> Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with java.util.concurrent.ConcurrentHashMap
> ------------------------------------------------------------------------------------------------------------
>                 Key: CLK-636
>                 URL:
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 2.2.0
>            Reporter: Henry Saputra
>         Attachments: concurrentreader_patch.diff
> Since Click required Java SDK 1.5 or later, we could leverage the java.util.concurrent.ConcurrentHashMap
class to replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class so reducing
the Click runtime dependency.
> In my opinion here are some good reasons why:
> 1. The ConcurrentHashMap class in Java SDK is more efficient since it utilizes internal
hash classes to support better granularity and concurrency compare to simple syncrhonized
on the instance like in DU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.
> 2. Looking at the use case ConcurrentReaderHashMap in Click, it used to cache the OGNL
expression (please correct me if I am wrong). This scenario does not need exclusive lock on
update which is the intended/ preferred use case for ConcurrentReaderHashMap. If there is
a miss on OGNL expression on a name in the cache, it will cerate one and put it to the map
if no other thread has not. So it will still perform as well as or better locking entire table.
However, if we do need exclusive lock on update, we can simulate ConcurrentReaderHashMap with
ConcurrentHashMap by setting concurrencyLevel to one.
> 3. The ConcurrentHashMap support generic which is part of task being done to move Click
code to Java generics.
> 4. Looks like the EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class is created
by Doug Lea before contributions to java.util.concurrent packages in Java 1.5 SDK so the code
may no longer optimized.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message