Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 14 Oct 2011 20:06:11 +0000 (UTC)
From: "Daniel Pitts (Commented) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <1542155558.15394.1318622771867.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <872907710.17472.1315239251255.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (OGNL-20) Performance - Replace synchronized
 blocks with ReentrantReadWriteLock
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127818#comment-13127818 ] 

Daniel Pitts commented on OGNL-20:
----------------------------------

{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. 
{quote}
In these cases, the cache key should *not* be the Class instance, but should instead be a tuple of <Class,Property>
This does change the existing caching semantics, but in my opinion it would *fix* the semantics.


> 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