[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108014#comment-13108014
]
Daniel Pitts commented on OGNL-20:
----------------------------------
Adrian: You mean the patch I attached? I'm pretty sure none of them have
"concurrency issues", unless you mean contention issues. I think we've decided
on ConcurrentHashMap anyway, but I'd still like to know what the issues are you
see.
ConcurrentHashMap is the only solution which doesn't have contention issues
under high load. Relieving the contention issue does leave a sort of race
condition however. Two threads may try to create the same entry, and the work
gets done multiple times. There may be other ways around that issue too, but
my gut it is an edge case under such extreme load that it wouldn't be the first
part of the system to break-down in most cases.
The appropriate solution would be to synchronize on the key (if it is a
singleton such as Class), or create a lazy (or "Future") value which can safely
be access concurrently, and guarantees only a single thread does the work.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
> Reporter: Greg Lively
> Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
>
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
