commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maurizio Cucchiara (Commented) (JIRA)" <>
Subject [jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
Date Thu, 13 Oct 2011 10:23:11 GMT


Maurizio Cucchiara commented on OGNL-20:

Hi Daniel,
First suggestion is ditch the ClassCacheEntryFactory interface, it doesn't do anything useful,
and prevents people from supplying CacheEntryFactory<Class<?>, ...> in its stead.
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...
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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message