[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108041#comment-13108041
]
Daniel Pitts commented on OGNL-20:
----------------------------------
Thanks for your feedback Adrian, I appreciate it.
The caches aren't intended to be "singleton sources", which is what you're
saying is the problem. From what I can see, the cached data isn't manipulated,
only queried. I have *not* done an exhaustive verification. I was mostly doing
this to benchmark the speed of various approaches. Those two methods could use
a double-check to enforce singletons if that was a true requirement. This of
course would add more overhead, and they are already loosing in the benchmarks.
Another note is that mutable objects which are not thread safe will continue to
not be thread safe to access, regardless of the thread-safety of storage
method.
> 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
