[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-1115: ---------------------------------- Affects Version/s: (was: 5.0.0.FINAL) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1115: -------------------------------- Assignee: Vladimir Blagojevic (was: Manik Surtani) Fix Version/s: 5.1.0.ALPHA2 (was: 5.1.0.BETA1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1115: ----------------------------------- Fix Version/s: 5.1.0.BETA2 (was: 5.1.0.BETA1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-1115: ------------------------------------------- I don't think so. How else can we invoke a method on cache from a fairly high-abstraction like AtomicHashMapProxy? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1115: ------------------------------------- @galderz +1 Adding a public method(i.e. AdvancedCache.applyDelta) for the single purpose[1] of being invoked by the internal code is a poor API design decision. [1] or is this method useful for other clients as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-1115: ------------------------------------------- I agree with Randall here and I do not see an alternate or even a better approach. Having applyDelta in AdvancedCache makes a lot of sense. Stick DeltaAware object into a cache (this could be some large XML for example) and repeatedly applyDelta on this DeltaAware transactionally! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1115 at 10/13/11 7:29 AM: --------------------------------------------------------------- @Randhall @Vladimir if there are any other delta aware requirements it's fine by me. An example of a use case, besides fine grained maps, that requires delta aware would be very convincing for me :-) was (Author: mircea.markus): @Randhall @Vladimir if there are any other delta aware requirements it's fine by me. An example for a use case, besides fine grained map, that requires delta aware would be very convincing for me :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Randall Hauch edited comment on ISPN-1115 at 10/13/11 9:08 AM: --------------------------------------------------------------- I've reused the DeltaAware functionality in my prototype for ISPN-1103, which has to do with a soft schema-based solution using JSON documents and JSON Schema documents. (The SchematicValue actually contains an in-memory representation of a JSON/BSON document, since storing a string would require parsing the string before use. These values are externalized using the BSON format.) Ideally the [SchematicEntry|https://github.com/rhauch/infinispan/blob/ISPN-1103/schema...] (akin to AtomicMap) could use fine-grained locks on the individual fields (potentially in nested documents). However, we need a way to plug this 'custom' delta-aware value into Infinispan and it's fine-grained locking capability. Note that I've tried to follow the same pattern as AtomicMap (interface), AtomicHashMap (impl), AtomicMapDelta (Delta impl), and AtomicHashMapProxy (proxy that hides the delta and atomic-ness). See the [branch|https://github.com/rhauch/infinispan/tree/ISPN-1103/schematic/src/...] for details. I am looking for feedback on ISPN-1103, so if interested please comment on that issue. was (Author: rhauch): I've reused the DeltaAware functionality in my prototype for ISPN-1103, which has to do with a soft schema-based solution using JSON documents and JSON Schema documents. (The SchematicValue actually contains an in-memory representation of a JSON/BSON document, since storing a string would require parsing the string before use.) Ideally the [SchematicEntry|https://github.com/rhauch/infinispan/blob/ISPN-1103/schema...] (akin to AtomicMap) could use fine-grained locks on the individual fields (potentially in nested documents). However, we need a way to plug this 'custom' delta-aware value into Infinispan and it's fine-grained locking capability. Note that I've tried to follow the same pattern as AtomicMap (interface), AtomicHashMap (impl), AtomicMapDelta (Delta impl), and AtomicHashMapProxy (proxy that hides the delta and atomic-ness). See the [branch|https://github.com/rhauch/infinispan/tree/ISPN-1103/schematic/src/...] for details. I am looking for feedback on ISPN-1103, so if interested please comment on that issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Manik Surtani commented on ISPN-1115: ------------------------------------- @Randall I know I owe you comment on the Soft Schema patch - I'm getting to it, I promise! :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1115?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1115: ----------------------------------- Fix Version/s: 5.1.0.BETA3 (was: 5.1.0.BETA2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira