[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108792#comment-13108792
]
Daniel Pitts commented on OGNL-20:
----------------------------------
I understand that the DCL is a broken pattern, what I suggested isn't a DCL. If
you don't understand *why* its different, then either you haven't read my posts
carefully or you don't understand why the DCL is broken. Hopefully you re-read
both that article which you posted and my posts here are well.
I fully understand what your concerns are about the other implementations, but
I disagree that they are real issues. If you stipulate in the get() contract
that the values may be different for the same key, then the contract is easier
to provide. It is also not that difficult to solve the problem you have
perceived.
Let's move on and avoid a flame war. This is not the appropriate place to have
these kinds of discussions. If you wish to continue discussing these, lets do
it somewhere more appropriate (perhaps
https://groups.google.com/group/comp.lang.java.programmer/topics?pli=1)
Adrian, thank you for being concerned about this project. I want this project
to succeed and be clean; I'm glad you do too, but please don't assume I
understand less than you. I've been writing software for a *long* time, and
have kept up on my reading.
I agree with your conclusion however that the ConcurrentHashMap *is* the
approach we want to take. My refactoring doesn't work out of the box anyway
because currently some of the "cached" values depend on more than the cache key
(which is also an anti-pattern, and should be examined in another Jira).
So, let us leave this conversation at that (use ConcurrentHashMap), which
hopefully will make both you and I happy. If you are still unhappy about the
rest of the conversation, I'll be glad to continue it
comp.lang.java.programmer. I will no long respond to such a conversation here.
Thanks,
Daniel.
> 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
