"put(K, V) is overloaded with put(K, V, String group)" Instead of using a String could this be changed to Object? We've tested this feature in the past with other systems and typically for us our "group" is not a String. Yes, we could convert our objects to Strings but I'm not sure I see the point if this could just be an Object. Also, I'm not sure why annotations wouldn't work if the annotation is for the method to invoke to get the group and not statically defining a group. Other systems I've used employ this technique. Annotations are fine as an option (if they work for this case) but as with my post in the user forum if you were to go this route I'd like it if there were an option of defining this as in a configuration file as well to not put constraints on the object model we create. Bryan From: infinispan-dev-bounces(a)lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani Sent: Monday, March 22, 2010 9:45 AM To: infinispan -Dev List Subject: [infinispan-dev] A mechanism for users to control data localitywhen using DIST So there have been some requests for this ability [1], and although I did blog about some strategies to achieve this [2], one of which Brian plans to employ for HTTP session state in JBoss AS 6, I think this is something generally useful and a simpler "user" solution should be offered. Annotations won't work for a number of reasons (mainly because this affinity information should be associated with a key instance, not a key class). So here is what I propose, from an API perspective: put(K, V) is overloaded with put(K, V, String group). "group" is an arbitrary, user-defined string, and it is up to the API user to ensure these are unique, and related entries are properly grouped. Note that this is similar in some ways to another JIRA proposed by Mindaugas Žakšauskas some months ago: ISPN-312 [3]. In terms of implementation, I expect we could add a DataAffinityInterceptor which would: * for puts, instead of putting (K, V) in the cache, it would put (group, AtomicMap) and (K, group) in the cache, and (K, V) in the AtomicMap. Similar behaviour for other writes. * for gets, instead of retrieving (K), from the cache, it would retrieve K to get the group id, and then retrieve the atomic map related to the group before retrieving the key. The effect of this is to hide the complexities of interacting with AtomicMaps from users by providing a convenience API. What do people think? Cheers Manik [1] https://jira.jboss.org/jira/browse/ISPN-359 [2] http://infinispan.blogspot.com/2009/08/distribution-instead-of-buddy.html [3] https://jira.jboss.org/jira/browse/ISPN-312 -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

"Again, annotations or a "producer" method could be additional ways to do this, but none of these remove the need for being able to do so on the API as above. And if it is on the API, then is there any real value in allowing annotations/producer methods?" I think the need for annotations/configuration of the group depends on your usage. If you want support grouping but hide the details of how and what groups a set of classes/object instances, etc map to then annotations/configuration easily give you that ability. Of course this could be done by writing a layer that does this for us but if it's there as part of the core then all the better. The only reason I bring this up is it sounded as if you didn't see value in annotations/configuration or thought it wouldn't work using annotations/configuration for this and you were only going to implement the new API. I just wanted to provide feedback that I do feel it's valuable. I may have misunderstood what you're planning. Bryan From: infinispan-dev-bounces(a)lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani Sent: Tuesday, March 23, 2010 1:23 PM To: infinispan -Dev List Subject: Re: [infinispan-dev] A mechanism for users to control datalocalitywhen using DIST On 23 Mar 2010, at 18:53, Bryan Grunow wrote: "put(K, V) is overloaded with put(K, V, String group)" Instead of using a String could this be changed to Object? We've tested this feature in the past with other systems and typically for us our "group" is not a String. Yes, we could convert our objects to Strings but I'm not sure I see the point if this could just be an Object. Fair point, it doesn't have to be a String. Also, I'm not sure why annotations wouldn't work if the annotation is for the method to invoke to get the group and not statically defining a group. Other systems I've used employ this technique. Annotations are fine as an option (if they work for this case) but as with my post in the user forum if you were to go this route I'd like it if there were an option of defining this as in a configuration file as well to not put constraints on the object model we create. Again, annotations or a "producer" method could be additional ways to do this, but none of these remove the need for being able to do so on the API as above. And if it is on the API, then is there any real value in allowing annotations/producer methods? Bryan From: infinispan-dev-bounces(a)lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani Sent: Monday, March 22, 2010 9:45 AM To: infinispan -Dev List Subject: [infinispan-dev] A mechanism for users to control data localitywhen using DIST So there have been some requests for this ability [1], and although I did blog about some strategies to achieve this [2], one of which Brian plans to employ for HTTP session state in JBoss AS 6, I think this is something generally useful and a simpler "user" solution should be offered. Annotations won't work for a number of reasons (mainly because this affinity information should be associated with a key instance, not a key class). So here is what I propose, from an API perspective: put(K, V) is overloaded with put(K, V, String group). "group" is an arbitrary, user-defined string, and it is up to the API user to ensure these are unique, and related entries are properly grouped. Note that this is similar in some ways to another JIRA proposed by Mindaugas Žakšauskas some months ago: ISPN-312 [3]. In terms of implementation, I expect we could add a DataAffinityInterceptor which would: * for puts, instead of putting (K, V) in the cache, it would put (group, AtomicMap) and (K, group) in the cache, and (K, V) in the AtomicMap. Similar behaviour for other writes. * for gets, instead of retrieving (K), from the cache, it would retrieve K to get the group id, and then retrieve the atomic map related to the group before retrieving the key. The effect of this is to hide the complexities of interacting with AtomicMaps from users by providing a convenience API. What do people think? Cheers Manik [1] https://jira.jboss.org/jira/browse/ISPN-359 [2] http://infinispan.blogspot.com/2009/08/distribution-instead-of-buddy.html [3] https://jira.jboss.org/jira/browse/ISPN-312 -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.