“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@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
Lead, Infinispan
Lead, JBoss Cache