[
https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840108#action_12840108
]
Adrian A. commented on CLK-636:
-------------------------------
> I have tried this before and it caused strange object instantiation errors
> with Spring.
> I was not able to determine the underlying cause.
I was experiencing the same problems.
Especially on WebSphere and Weblogic users complained about such problems, so
we reverted back the patch.
> 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
>
> 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.
