[infinispan-issues] [JBoss JIRA] Updated: (ISPN-1115) Fine-grained AtomicMaps

[Manik Surtani (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manik Surtani updated ISPN-1115:
--------------------------------

    Description: 
Atomic Maps are locked by acquiring a single lock on the entire map and this causes concurrency issues for certain use cases.  This JIRA is to allow for concurrent modifications of keys within the AtomicMap, provided the keys do not overlap.

The design is as follows:

* {{AtomicMapLookup}} gets a WL on the {{AtomicMap}}'s key (AMK) when creating and removing a new AtomicMap
* Modifications to the AtomicMap (which go through the {{AtomicMapProxy}}) do _not_ acquire a WL on AMK.  Instead,
* {{AdvancedCache}} exposes a new API, {{applyDelta(K deltaAwareValueKey, Delta delta, Object... locksToAcquire)}}
* {{AtomicMapProxy}} makes changes by calling {{applyDelta}} and passing in the key within the map that is being modified, along with the delta to apply.
  * The implementation could offer lock pooling to prevent a large number of locks being created for AtomicMaps with a large number of entries
* On detecting concurrent deletion, updates would fail.

This can then be used by other {{Delta}}/{{DeltaAware}} types in future as well, perhaps JSON documents, etc.

  was:
Atomic Maps are locked by acquiring a single lock on the entire map and this causes concurrency issues for certain use cases.  This JIRA is to allow for concurrent modifications of keys within the AtomicMap, provided the keys do not overlap.

The design is as follows:

* {{AtomicMapLookup}} gets a WL on the {{AtomicMap}}'s key (AMK) when creating and removing a new AtomicMap
* Modifications to the AtomicMap (which go through the {{AtomicMapProxy}}) do _not_ acquire a WL on AMK.  Instead,
* {{AdvancedCache}} exposes a new API, {{applyDelta(K deltaAwareValueKey, Delta delta, Object... locksToAcquire)}}
* {{AtomicMapProxy}} makes changes by calling {{applyDelta}} and passing in the key within the map that is being modified, along with the delta to apply.
  * The implementation could offer lock pooling to prevent a large number of locks being created for AtomicMaps with a large number of entries

This can then be used by other {{Delta}}/{{DeltaAware}} types in future as well, perhaps JSON documents, etc.



> Fine-grained AtomicMaps
> -----------------------
>
>                 Key: ISPN-1115
>                 URL: https://issues.jboss.org/browse/ISPN-1115
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Core API
>    Affects Versions: 5.0.0.FINAL
>            Reporter: Manik Surtani
>            Assignee: Manik Surtani
>             Fix For: 5.1.0.BETA1, 5.1.0.Final
>
>
> Atomic Maps are locked by acquiring a single lock on the entire map and this causes concurrency issues for certain use cases.  This JIRA is to allow for concurrent modifications of keys within the AtomicMap, provided the keys do not overlap.
> The design is as follows:
> * {{AtomicMapLookup}} gets a WL on the {{AtomicMap}}'s key (AMK) when creating and removing a new AtomicMap
> * Modifications to the AtomicMap (which go through the {{AtomicMapProxy}}) do _not_ acquire a WL on AMK.  Instead,
> * {{AdvancedCache}} exposes a new API, {{applyDelta(K deltaAwareValueKey, Delta delta, Object... locksToAcquire)}}
> * {{AtomicMapProxy}} makes changes by calling {{applyDelta}} and passing in the key within the map that is being modified, along with the delta to apply.
>   * The implementation could offer lock pooling to prevent a large number of locks being created for AtomicMaps with a large number of entries
> * On detecting concurrent deletion, updates would fail.
> This can then be used by other {{Delta}}/{{DeltaAware}} types in future as well, perhaps JSON documents, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira