[ https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126472#comment-13126472 ]
Maurizio Cucchiara commented on OGNL-20: ---------------------------------------- Hi Daniel, {quote} First suggestion is ditch the ClassCacheEntryFactory interface, it doesn't do anything useful, and prevents people from supplying CacheEntryFactory<Class<?>, ...> in its stead. {quote} Agreed {quote} Also, CacheEntryFactory instances are intended to be flyweights, where you've actually been instantiating them every time you need them. For example, I suggest refactoring getConstructors... {quote} Unfortunately, not everything turns out as it should, I would have like to use flyweights, but it is not always a suitable pattern: not every cache has a so simple "miss" condition. Take for example {{getDeclaredMethods}} which, given a property name, returns the list of the declared methods along the hierarchy. Now, in this specific case, the "miss" condition is absolutely property-dependent, it is not enough that a cache contains information about a given class. Even if I don't like much, I am afraid that the only solution is to use not-anonymous classes. This strongly increases the classes's proliferation, but it's the only solution I am able to see. It is not easy to explain for me, I hope I did it well. > 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira