[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108188#comment-13108188
]
Daniel Pitts commented on OGNL-20:
----------------------------------
I have read many times Java Concurrency in Practice, and have a lot of personal
experience with the Java Memory Model and thinking about concurrency.
I think I miscommunicated the solution I meant for the use-cases you're
concerned of.
The order of operations:
1. acquire-lock.
2. Grab item out of cache map.
3. release lock.
4. return item if not null.
5. acquire-lock.
6. Grab item again.
7. return item if not null, releasing lock.
8. Generate new item.
9. Store in cache.
10. release lock.
11. return newly generated item.
That will always return the same item, unless some other process updates the
cache map.
Again, this is a moot point since the Cache requirements don't seem to need
"singleton" status.
> 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
