[ 
https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrian A. closed CLK-636.
-------------------------


closing issue fixed a long time ago.

> Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with 
> java.util.concurrent.ConcurrentHashMap
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: CLK-636
>                 URL: https://issues.apache.org/jira/browse/CLK-636
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 2.2.0
>            Reporter: Henry Saputra
>            Assignee: Bob Schellink
>            Priority: Minor
>             Fix For: 2.3.0-M1
>
>         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 was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to