You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (Closed) (JIRA)" <ji...@apache.org> on 2012/02/22 19:35:49 UTC

[jira] [Closed] (CAY-1670) Non-blocking DataRowStore

     [ https://issues.apache.org/jira/browse/CAY-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrus Adamchik closed CAY-1670.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 3.1M4
    
> Non-blocking DataRowStore
> -------------------------
>
>                 Key: CAY-1670
>                 URL: https://issues.apache.org/jira/browse/CAY-1670
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.1M3
>            Reporter: Andrus Adamchik
>            Assignee: Andrus Adamchik
>             Fix For: 3.1M4
>
>
> Until we decide on unifying object and query caches, it would be cool if we could remove the shared lock from DataRowStore that causes issues like CAY-1124, and generally creates contention on access from multiple threads. 
> We would need some kind of cross-over between LinkedHashMap (that allows to set up LRU policies among other things) and ConcurrentHashMap. There are a few solutions out there that may provide needed characteristics:
> 1. http://code.google.com/p/concurrentlinkedhashmap/ (the quality is unclear)
> 2. Guava MapMaker  http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/MapMaker.html (is it based on #1?)
> #2 will require a huge 1.7MB Guava lib as a dependency for Cayenne. So maybe experiment with #1...
> 3. Also was thinking of useing JDK ConcurrentHashMap, and implementing a FIFO eviction mechanism instead of LRU. FIFO should be easier to implement in our code. This change has a chance to cause havoc in Cayenne though (snapshots just loaded would get kicked out within the same transaction).
> Another issue which is agnostic to whatever implementation we'd chose, is what happens when certain operations become non-atomic when we remove synchronized blocks:
>       synchronized (this) {
>             processDeletedIDs(deletedSnapshotIds);
>             processInvalidatedIDs(invalidatedSnapshotIds);
>             processUpdateDiffs(diffs);
>             sendUpdateNotification(
>                     event.getPostedBy(),
>                     diffs,
>                     deletedSnapshotIds,
>                     invalidatedSnapshotIds,
>                     indirectlyModifiedIds);
>         }
> Anyways this will require some research and testing.

--
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