commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi (JIRA)" <>
Subject [jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
Date Fri, 09 Sep 2011 06:17:08 GMT


Simone Tripodi commented on OGNL-20:

Sorry, I just figure out that I explained so bad to get wrong - English improvement is still
in my TODO list ;)
The key point is that the current implementation is justified by historical reasons - first
OGNL release date is the far '97 - and never changed since it was working :)

Maurizio already did some performances tests, using different cache backend implementations,
which results have to be shared, as far as I remember the current implementation was one of
the faster if not the faster.

Anyway if you want to contribute with performances tests, you are more than welcome, and thanks
for sharing your thoughts!

> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> ---------------------------------------------------------------------
>                 Key: OGNL-20
>                 URL:
>             Project: OGNL
>          Issue Type: Improvement
>         Environment: ALL
>            Reporter: Greg Lively
> 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:


View raw message