2:36 p.m.
Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a couple of
approaches that could be taken:
1. Don't use key.hashcode() as the seed in determining to which nodes an entry is
mapped, but instead on a well-known method or annotated method (e.g., int getGroupID() or
a method annotated with @GroupId). The way I see it, this approach has:
+ Will work, no additional overheads of AtomicMaps
- Cost (reflection)
- Intrusive (what if users have no control over the key class, e.g., String keys?)
2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map, G), etc.
+ Non-intrusive
- Overhead of AtomicMaps + additional entries for mappings
+ or - (depending on how you look at it) all keys in the group will be locked together,
etc, a side-effect of using AtomicMaps
My pref is for approach #2. In terms of implementation, here is what I have in mind:
* A GroupingInterceptor that intercepts the call early on if the call is a put(K, V, G) or
something similar.
* Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in a tx to
ensure atomicity.
* get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
* remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
One of the issues with the API approach is that it heavily pollutes the Cache API. It
will double the number of put() methods on Cache (currently 18 variants of put, including
ones that take in lifespans and maxIdles, async versions that return futures, etc.)
Perhaps this could be in an additional sub-interface interface? GroupedCache? Or is this
degree of method overloading not too confusing?
Cheers,
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
2:58 p.m.
On 12 Apr 2010, at 15:36, Manik Surtani wrote:
Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there
are a couple of approaches that could be taken:
1. Don't use key.hashcode() as the seed in determining to which nodes an entry is
mapped, but instead on a well-known method or annotated method (e.g., int getGroupID() or
a method annotated with @GroupId). The way I see it, this approach has:
+ Will work, no additional overheads of AtomicMaps
- Cost (reflection)
- Intrusive (what if users have no control over the key class, e.g., String keys?)
2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map, G), etc.
+ Non-intrusive
- Overhead of AtomicMaps + additional entries for mappings
+ or - (depending on how you look at it) all keys in the group will be locked together,
etc, a side-effect of using AtomicMaps
My pref is for approach #2. In terms of implementation, here is what I have in mind:
* A GroupingInterceptor that intercepts the call early on if the call is a put(K, V, G)
or something similar.
* Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in a tx to
ensure atomicity.
* get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
* remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
One of the issues with the API approach is that it heavily pollutes the Cache API. It
will double the number of put() methods on Cache (currently 18 variants of put, including
ones that take in lifespans and maxIdles, async versions that return futures, etc.)
Perhaps this could be in an additional sub-interface interface? GroupedCache? Or is this
degree of method overloading not too confusing?
what about using an Flag-like api?
cache.inGroup("groupName").put(...).
or an "parametrized" flag:
cache.withFlag(Flags.getColocateFlag("grouName").put(...)
as long as we can create "parametrized" flags as bellow, I like the second
approach
Cheers,
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:30 p.m.
Why don't we ping Emmanuel for an advice. He's done similar API design in
Hibernate IIRC.
On 2010-04-12, at 8:58 AM, Mircea Markus wrote:
On 12 Apr 2010, at 15:36, Manik Surtani wrote:
> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a couple of
approaches that could be taken:
>
> 1. Don't use key.hashcode() as the seed in determining to which nodes an entry
is mapped, but instead on a well-known method or annotated method (e.g., int getGroupID()
or a method annotated with @GroupId). The way I see it, this approach has:
>
> + Will work, no additional overheads of AtomicMaps
> - Cost (reflection)
> - Intrusive (what if users have no control over the key class, e.g., String keys?)
>
> 2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map, G),
etc.
>
> + Non-intrusive
> - Overhead of AtomicMaps + additional entries for mappings
> + or - (depending on how you look at it) all keys in the group will be locked
together, etc, a side-effect of using AtomicMaps
>
> My pref is for approach #2. In terms of implementation, here is what I have in
mind:
>
> * A GroupingInterceptor that intercepts the call early on if the call is a put(K, V,
G) or something similar.
> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in a tx
to ensure atomicity.
> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>
> One of the issues with the API approach is that it heavily pollutes the Cache API.
It will double the number of put() methods on Cache (currently 18 variants of put,
including ones that take in lifespans and maxIdles, async versions that return futures,
etc.) Perhaps this could be in an additional sub-interface interface? GroupedCache? Or
is this degree of method overloading not too confusing?
what about using an Flag-like api?
cache.inGroup("groupName").put(...).
or an "parametrized" flag:
cache.withFlag(Flags.getColocateFlag("grouName").put(...)
as long as we can create "parametrized" flags as bellow, I like the second
approach
>
> Cheers,
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:55 a.m.
No need, Marcus had it :)
I'd do something like
cacheFactory.usingContext()
.colocateOn(groupName)
.getCache() (*)
(*) assuming the ability to get a cache is
Or is the collocation business something that must be done at the cache level temporarily
/ for a single operation (thus hosted on the cache interface)?
On 12 avr. 2010, at 15:30, Vladimir Blagojevic wrote:
Why don't we ping Emmanuel for an advice. He's done similar
API design in Hibernate IIRC.
On 2010-04-12, at 8:58 AM, Mircea Markus wrote:
>
> On 12 Apr 2010, at 15:36, Manik Surtani wrote:
>
>> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a couple
of approaches that could be taken:
>>
>> 1. Don't use key.hashcode() as the seed in determining to which nodes an
entry is mapped, but instead on a well-known method or annotated method (e.g., int
getGroupID() or a method annotated with @GroupId). The way I see it, this approach has:
>>
>> + Will work, no additional overheads of AtomicMaps
>> - Cost (reflection)
>> - Intrusive (what if users have no control over the key class, e.g., String
keys?)
>>
>> 2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map,
G), etc.
>>
>> + Non-intrusive
>> - Overhead of AtomicMaps + additional entries for mappings
>> + or - (depending on how you look at it) all keys in the group will be locked
together, etc, a side-effect of using AtomicMaps
>>
>> My pref is for approach #2. In terms of implementation, here is what I have in
mind:
>>
>> * A GroupingInterceptor that intercepts the call early on if the call is a put(K,
V, G) or something similar.
>> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in
a tx to ensure atomicity.
>> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
>> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>>
>> One of the issues with the API approach is that it heavily pollutes the Cache
API. It will double the number of put() methods on Cache (currently 18 variants of put,
including ones that take in lifespans and maxIdles, async versions that return futures,
etc.) Perhaps this could be in an additional sub-interface interface? GroupedCache? Or
is this degree of method overloading not too confusing?
> what about using an Flag-like api?
> cache.inGroup("groupName").put(...).
> or an "parametrized" flag:
> cache.withFlag(Flags.getColocateFlag("grouName").put(...)
> as long as we can create "parametrized" flags as bellow, I like the second
approach
>
>>
>> Cheers,
>> --
>> Manik Surtani
>> manik(a)jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:28 a.m.
On 13 Apr 2010, at 07:55, Emmanuel Bernard wrote:
No need, Marcus had it :)
I'd do something like
cacheFactory.usingContext()
.colocateOn(groupName)
.getCache() (*)
(*) assuming the ability to get a cache is
Or is the collocation business something that must be done at the cache level temporarily
/ for a single operation (thus hosted on the cache interface)?
The latter. So something like:
cache.inGroup("coloGrp1").put("k1", "v1");
cache.inGroup("coloGrp1").put("k2", "v2");
cache.inGroup("coloGrp2").put("k3", "v3");
cache.inGroup("coloGrp2").put("k4", "v4");
would result in k1 and k2 being placed on the same nodes, regardless of what the 2 keys
individually hash to. Same with k3 and k4.
Another question (slightly off-topic) - would people then be tempted to use this as a
scoping mechanism:
cache.inGroup("coloGrp1").put("name", "Manik");
cache.inGroup("coloGrp1").put("location", "London");
cache.inGroup("coloGrp2").put("name", "Emmanuel");
cache.inGroup("coloGrp2").put("location", "Paris");
since this will *not* work. The cache still primarily is a collection of K -> V
mappings and in the above case the last 2 lines will effectively overwrite the 1st 2
lines.
Cheers
Manik
On 12 avr. 2010, at 15:30, Vladimir Blagojevic wrote:
> Why don't we ping Emmanuel for an advice. He's done similar API design in
Hibernate IIRC.
> On 2010-04-12, at 8:58 AM, Mircea Markus wrote:
>
>>
>> On 12 Apr 2010, at 15:36, Manik Surtani wrote:
>>
>>> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a
couple of approaches that could be taken:
>>>
>>> 1. Don't use key.hashcode() as the seed in determining to which nodes an
entry is mapped, but instead on a well-known method or annotated method (e.g., int
getGroupID() or a method annotated with @GroupId). The way I see it, this approach has:
>>>
>>> + Will work, no additional overheads of AtomicMaps
>>> - Cost (reflection)
>>> - Intrusive (what if users have no control over the key class, e.g., String
keys?)
>>>
>>> 2. Additional API methods on the cache - cache.put(K, V, G),
cache.putAll(Map, G), etc.
>>>
>>> + Non-intrusive
>>> - Overhead of AtomicMaps + additional entries for mappings
>>> + or - (depending on how you look at it) all keys in the group will be locked
together, etc, a side-effect of using AtomicMaps
>>>
>>> My pref is for approach #2. In terms of implementation, here is what I have
in mind:
>>>
>>> * A GroupingInterceptor that intercepts the call early on if the call is a
put(K, V, G) or something similar.
>>> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped
in a tx to ensure atomicity.
>>> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
>>> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>>>
>>> One of the issues with the API approach is that it heavily pollutes the Cache
API. It will double the number of put() methods on Cache (currently 18 variants of put,
including ones that take in lifespans and maxIdles, async versions that return futures,
etc.) Perhaps this could be in an additional sub-interface interface? GroupedCache? Or
is this degree of method overloading not too confusing?
>> what about using an Flag-like api?
>> cache.inGroup("groupName").put(...).
>> or an "parametrized" flag:
>> cache.withFlag(Flags.getColocateFlag("grouName").put(...)
>> as long as we can create "parametrized" flags as bellow, I like the
second approach
>>
>>>
>>> Cheers,
>>> --
>>> Manik Surtani
>>> manik(a)jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
11:49 a.m.
On 13 avr. 2010, at 11:28, Manik Surtani wrote:
On 13 Apr 2010, at 07:55, Emmanuel Bernard wrote:
> No need, Marcus had it :)
>
> I'd do something like
>
> cacheFactory.usingContext()
> .colocateOn(groupName)
> .getCache() (*)
> (*) assuming the ability to get a cache is
>
> Or is the collocation business something that must be done at the cache level
temporarily / for a single operation (thus hosted on the cache interface)?
The latter. So something like:
cache.inGroup("coloGrp1").put("k1", "v1");
cache.inGroup("coloGrp1").put("k2", "v2");
cache.inGroup("coloGrp2").put("k3", "v3");
cache.inGroup("coloGrp2").put("k4", "v4");
would result in k1 and k2 being placed on the same nodes, regardless of what the 2 keys
individually hash to. Same with k3 and k4.
Another question (slightly off-topic) - would people then be tempted to use this as a
scoping mechanism:
cache.inGroup("coloGrp1").put("name", "Manik");
cache.inGroup("coloGrp1").put("location", "London");
cache.inGroup("coloGrp2").put("name", "Emmanuel");
cache.inGroup("coloGrp2").put("location", "Paris");
since this will *not* work. The cache still primarily is a collection of K -> V
mappings and in the above case the last 2 lines will effectively overwrite the 1st 2
lines.
For this use case, you could add a new method, something like
cache.scope("51thState").put("name", "Manik");
cache.scope("51thState").put("location", "London");
cache.scope("cheeseLand").put("name", "Emmanuel");
cache.scope("cheeseLand").put("location", "Paris");
which could prefix the key.
But as it breaks the natural semantic of Infinispan, I'm not sure it's worth the
addition.
Regardless, both APIs should also support something like that
ColocatedCache cc = cache.inGroup("cheeseLand"); //cache.collocateIn(String)?
cc.put("name", "Emmanuel");
cc.put("location", "Paris");
A specific interface (ala ColocatedCache) is preferable but boils down to:
- keep it (design) simple
- guide the API user and avoid mistakes (ie a ScopedCache cannot be scoped again same for
a collocated one I imagine).
11:58 a.m.
On 13 Apr 2010, at 10:49, Emmanuel Bernard wrote:
For this use case, you could add a new method, something like
cache.scope("51thState").put("name", "Manik");
cache.scope("51thState").put("location", "London");
cache.scope("cheeseLand").put("name", "Emmanuel");
cache.scope("cheeseLand").put("location", "Paris");
which could prefix the key.
But as it breaks the natural semantic of Infinispan, I'm not sure it's worth the
addition.
Well basically it is not something we want to support - not with this API. (This style of
"record management" is what you would use either the AtomicMap API or the
upcoming JPA-like API for).
The goal is to make this colocation grouping very clear that it is *not* intended for
scoping. :)
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
11:50 a.m.
2010/4/13 Manik Surtani <manik(a)jboss.org>:
On 13 Apr 2010, at 07:55, Emmanuel Bernard wrote:
No need, Marcus had it :)
I'd do something like
cacheFactory.usingContext()
.colocateOn(groupName)
.getCache() (*)
(*) assuming the ability to get a cache is
Or is the collocation business something that must be done at the cache
level temporarily / for a single operation (thus hosted on the cache
interface)?
The latter. So something like:
cache.inGroup("coloGrp1").put("k1", "v1");
cache.inGroup("coloGrp1").put("k2", "v2");
cache.inGroup("coloGrp2").put("k3", "v3");
cache.inGroup("coloGrp2").put("k4", "v4");
would result in k1 and k2 being placed on the same nodes, regardless of what
the 2 keys individually hash to. Same with k3 and k4.
Another question (slightly off-topic) - would people then be tempted to use
this as a scoping mechanism:
cache.inGroup("coloGrp1").put("name", "Manik");
cache.inGroup("coloGrp1").put("location", "London");
cache.inGroup("coloGrp2").put("name", "Emmanuel");
cache.inGroup("coloGrp2").put("location", "Paris");
since this will *not* work. The cache still primarily is a collection of K
-> V mappings and in the above case the last 2 lines will effectively
overwrite the 1st 2 lines.
Cheers
Manik
rightfull concern, I wouldn't personally have expected that but I'm
biased as I follow this thread; it's not hard to imagine some people
falling in this trap.
Sanne
On 12 avr. 2010, at 15:30, Vladimir Blagojevic wrote:
Why don't we ping Emmanuel for an advice. He's done similar API design in
Hibernate IIRC.
On 2010-04-12, at 8:58 AM, Mircea Markus wrote:
On 12 Apr 2010, at 15:36, Manik Surtani wrote:
Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a
couple of approaches that could be taken:
1. Don't use key.hashcode() as the seed in determining to which nodes an
entry is mapped, but instead on a well-known method or annotated method
(e.g., int getGroupID() or a method annotated with @GroupId). The way I see
it, this approach has:
+ Will work, no additional overheads of AtomicMaps
- Cost (reflection)
- Intrusive (what if users have no control over the key class, e.g., String
keys?)
2. Additional API methods on the cache - cache.put(K, V, G),
cache.putAll(Map, G), etc.
+ Non-intrusive
- Overhead of AtomicMaps + additional entries for mappings
+ or - (depending on how you look at it) all keys in the group will be
locked together, etc, a side-effect of using AtomicMaps
My pref is for approach #2. In terms of implementation, here is what I have
in mind:
* A GroupingInterceptor that intercepts the call early on if the call is a
put(K, V, G) or something similar.
* Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V).
Wrapped in a tx to ensure atomicity.
* get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
* remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
One of the issues with the API approach is that it heavily pollutes the
Cache API. It will double the number of put() methods on Cache (currently
18 variants of put, including ones that take in lifespans and maxIdles,
async versions that return futures, etc.) Perhaps this could be in an
additional sub-interface interface? GroupedCache? Or is this degree of
method overloading not too confusing?
what about using an Flag-like api?
cache.inGroup("groupName").put(...).
or an "parametrized" flag:
cache.withFlag(Flags.getColocateFlag("grouName").put(...)
as long as we can create "parametrized" flags as bellow, I like the second
approach
Cheers,
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:01 p.m.
On 13 Apr 2010, at 10:50, Sanne Grinovero wrote:
rightfull concern, I wouldn't personally have expected that but
I'm
biased as I follow this thread; it's not hard to imagine some people
falling in this trap.
Yes; how do we make sure no one falls into this trap? :) How about:
cache.affinityKey("Blah").put(k, v)
The problem with "group" or even location/locality/colocation is that they can
all be misconstrued to mean "scope". With something like "affinity",
I suppose it is clearer?
WDYT?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
4:31 p.m.
So thinking about this some more, it would seem that there is a bit more to this. We can
add the functionality easily enough, and add the API to the Cache interface.
But would people would reasonably expect this kind of functionality over Hot Rod as well?
And would we need to think about exposing this in Hot Rod too? Or would this kind of
functionality be implemented in the Hot Rod client if needed, so the protocol remains
unchanged?
On 13 Apr 2010, at 11:01, Manik Surtani wrote:
On 13 Apr 2010, at 10:50, Sanne Grinovero wrote:
> rightfull concern, I wouldn't personally have expected that but I'm
> biased as I follow this thread; it's not hard to imagine some people
> falling in this trap.
Yes; how do we make sure no one falls into this trap? :) How about:
cache.affinityKey("Blah").put(k, v)
The problem with "group" or even location/locality/colocation is that they can
all be misconstrued to mean "scope". With something like "affinity",
I suppose it is clearer?
WDYT?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
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
4:42 p.m.
On 13 Apr 2010, at 11:01, Manik Surtani wrote:
On 13 Apr 2010, at 10:50, Sanne Grinovero wrote:
> rightfull concern, I wouldn't personally have expected that but I'm
> biased as I follow this thread; it's not hard to imagine some people
> falling in this trap.
Yes; how do we make sure no one falls into this trap? :) How about:
cache.affinityKey("Blah").put(k, v)
The problem with "group" or even location/locality/colocation is that they can
all be misconstrued to mean "scope". With something like "affinity",
I suppose it is clearer?
Here is an alternative - *do* we want to support scoping? By this, I mean:
cache.withAffinityKey("k1").put("name", "Manik");
cache.withAffinityKey("k1").put("country", "UK");
cache.withAffinityKey("k2").put("name", "Sanne");
cache.withAffinityKey("k2").put("country", "IT");
will be allowed and the two will not overwrite each other, *but* you cannot retrieve stuff
by simply doing:
cache.get("name") anymore. You would have to do:
cache.withAffinityKey("k1").get("name"). Simply doing a
cache.get("name") will return a null.
What do people prefer?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
11:54 a.m.
On 13 Apr 2010, at 12:28, Manik Surtani wrote:
On 13 Apr 2010, at 07:55, Emmanuel Bernard wrote:
> No need, Marcus had it :)
>
> I'd do something like
>
> cacheFactory.usingContext()
> .colocateOn(groupName)
> .getCache() (*)
> (*) assuming the ability to get a cache is
>
> Or is the collocation business something that must be done at the cache level
temporarily / for a single operation (thus hosted on the cache interface)?
The latter. So something like:
cache.inGroup("coloGrp1").put("k1", "v1");
cache.inGroup("coloGrp1").put("k2", "v2");
cache.inGroup("coloGrp2").put("k3", "v3");
cache.inGroup("coloGrp2").put("k4", "v4");
would result in k1 and k2 being placed on the same nodes, regardless of what the 2 keys
individually hash to. Same with k3 and k4.
Another question (slightly off-topic) - would people then be tempted to use this as a
scoping mechanism:
cache.inGroup("coloGrp1").put("name", "Manik");
cache.inGroup("coloGrp1").put("location", "London");
cache.inGroup("coloGrp2").put("name", "Emmanuel");
cache.inGroup("coloGrp2").put("location", "Paris");
since this will *not* work. The cache still primarily is a collection of K -> V
mappings and in the above case the last 2 lines will effectively overwrite the 1st 2
lines.
"name" will only appear once in the cluster, (on different location
though), right?
Generally speaking I'm curious on how this scenario is handled:
node A: cache.inGroup("a").put("key","something");
node B: . assertEquals("something" ,cache.get("key")); //this assert
is correct
Cheers
Manik
>
>
> On 12 avr. 2010, at 15:30, Vladimir Blagojevic wrote:
>
>> Why don't we ping Emmanuel for an advice. He's done similar API design in
Hibernate IIRC.
>> On 2010-04-12, at 8:58 AM, Mircea Markus wrote:
>>
>>>
>>> On 12 Apr 2010, at 15:36, Manik Surtani wrote:
>>>
>>>> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are
a couple of approaches that could be taken:
>>>>
>>>> 1. Don't use key.hashcode() as the seed in determining to which
nodes an entry is mapped, but instead on a well-known method or annotated method (e.g.,
int getGroupID() or a method annotated with @GroupId). The way I see it, this approach
has:
>>>>
>>>> + Will work, no additional overheads of AtomicMaps
>>>> - Cost (reflection)
>>>> - Intrusive (what if users have no control over the key class, e.g.,
String keys?)
>>>>
>>>> 2. Additional API methods on the cache - cache.put(K, V, G),
cache.putAll(Map, G), etc.
>>>>
>>>> + Non-intrusive
>>>> - Overhead of AtomicMaps + additional entries for mappings
>>>> + or - (depending on how you look at it) all keys in the group will be
locked together, etc, a side-effect of using AtomicMaps
>>>>
>>>> My pref is for approach #2. In terms of implementation, here is what I
have in mind:
>>>>
>>>> * A GroupingInterceptor that intercepts the call early on if the call is
a put(K, V, G) or something similar.
>>>> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V).
Wrapped in a tx to ensure atomicity.
>>>> * get(K), etc intercepted as well, replaced with
getAtomicMap(get(K)).get(K)
>>>> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>>>>
>>>> One of the issues with the API approach is that it heavily pollutes the
Cache API. It will double the number of put() methods on Cache (currently 18 variants of
put, including ones that take in lifespans and maxIdles, async versions that return
futures, etc.) Perhaps this could be in an additional sub-interface interface?
GroupedCache? Or is this degree of method overloading not too confusing?
>>> what about using an Flag-like api?
>>> cache.inGroup("groupName").put(...).
>>> or an "parametrized" flag:
>>> cache.withFlag(Flags.getColocateFlag("grouName").put(...)
>>> as long as we can create "parametrized" flags as bellow, I like the
second approach
>>>
>>>>
>>>> Cheers,
>>>> --
>>>> Manik Surtani
>>>> manik(a)jboss.org
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:08 p.m.
On 13 Apr 2010, at 10:54, Mircea Markus wrote:
>
> since this will *not* work. The cache still primarily is a collection of K -> V
mappings and in the above case the last 2 lines will effectively overwrite the 1st 2
lines.
"name" will only appear once in the cluster, (on different location though),
right?
Yes, and hence the effective "overwriting" of the previous name.
Generally speaking I'm curious on how this scenario is handled:
node A: cache.inGroup("a").put("key","something");
node B: . assertEquals("something" ,cache.get("key")); //this assert
is correct
The interceptor would create these mappings on a put:
K -> G
G -> AtomicMap{K -> V}
and for a get:
return get(get(K)).get(K)
so in your example, after the put, you will find:
"key" -> "a"
"a" -> AtomicMap{"key" -> "something"}
Now when you do the get, the interceptor would:
grpId = get("key")
atomicMap = get(grpId)
return atomicMap.get("key")
"All problems in computer science can be solved by another level of indirection"
- David Wheeler
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
1:35 p.m.
On 13 Apr 2010, at 13:08, Manik Surtani wrote:
On 13 Apr 2010, at 10:54, Mircea Markus wrote:
>>
>> since this will *not* work. The cache still primarily is a collection of K ->
V mappings and in the above case the last 2 lines will effectively overwrite the 1st 2
lines.
> "name" will only appear once in the cluster, (on different location
though), right?
Yes, and hence the effective "overwriting" of the previous name.
> Generally speaking I'm curious on how this scenario is handled:
> node A: cache.inGroup("a").put("key","something");
> node B: . assertEquals("something" ,cache.get("key")); //this
assert is correct
The interceptor would create these mappings on a put:
K -> G
G -> AtomicMap{K -> V}
and for a get:
return get(get(K)).get(K)
so in your example, after the put, you will find:
"key" -> "a"
"a" -> AtomicMap{"key" -> "something"}
Now when you do the get, the interceptor would:
grpId = get("key")
where are you keeping this key to group mapping? I
guess this should be present on all nodes
atomicMap = get(grpId)
won't this fetch all the atomic map
over for all the calls?
return atomicMap.get("key")
"All problems in computer science can be solved by another level of
indirection" - David Wheeler
"For every complex problem, there is a
solution that is simple, neat and wrong" - H.L. Mencken
(don't think this is the case for this, but I couldn't help it :D )
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:47 p.m.
On 04/13/2010 05:08 AM, Manik Surtani wrote:
On 13 Apr 2010, at 10:54, Mircea Markus wrote:
>>
>> since this will *not* work. The cache still primarily is a collection of K ->
V mappings and in the above case the last 2 lines will effectively overwrite the 1st 2
lines.
> "name" will only appear once in the cluster, (on different location
though), right?
Yes, and hence the effective "overwriting" of the previous name.
> Generally speaking I'm curious on how this scenario is handled:
> node A: cache.inGroup("a").put("key","something");
> node B: . assertEquals("something" ,cache.get("key")); //this
assert is correct
The interceptor would create these mappings on a put:
K -> G
G -> AtomicMap{K -> V}
What if K itself is an AtomicMap (which in the session case being
discussed with Vladimir Ralev, it will be)?
and for a get:
return get(get(K)).get(K)
so in your example, after the put, you will find:
"key" -> "a"
"a" -> AtomicMap{"key" -> "something"}
Now when you do the get, the interceptor would:
grpId = get("key")
atomicMap = get(grpId)
return atomicMap.get("key")
"All problems in computer science can be solved by another level of
indirection" - David Wheeler
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5:15 p.m.
On 13 Apr 2010, at 14:47, Brian Stansberry wrote:
What if K itself is an AtomicMap (which in the session case being
discussed with Vladimir Ralev, it will be)?
Hmm - an AtomicMap as a key? That won't work ... not in this case, and not otherwise
as well.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
8:09 p.m.
On 04/13/2010 10:15 AM, Manik Surtani wrote:
On 13 Apr 2010, at 14:47, Brian Stansberry wrote:
> What if K itself is an AtomicMap (which in the session case being
> discussed with Vladimir Ralev, it will be)?
Hmm - an AtomicMap as a key? That won't work ... not in this case, and not otherwise
as well.
Sorry, that was brain dead on my part. K != V :-)
I'll drink my coffee before reading these kinds of threads from now on.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
3:34 p.m.
On 12 Apr 2010, at 13:58, Mircea Markus wrote:
On 12 Apr 2010, at 15:36, Manik Surtani wrote:
> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a couple of
approaches that could be taken:
>
> 1. Don't use key.hashcode() as the seed in determining to which nodes an entry
is mapped, but instead on a well-known method or annotated method (e.g., int getGroupID()
or a method annotated with @GroupId). The way I see it, this approach has:
>
> + Will work, no additional overheads of AtomicMaps
> - Cost (reflection)
> - Intrusive (what if users have no control over the key class, e.g., String keys?)
>
> 2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map, G),
etc.
>
> + Non-intrusive
> - Overhead of AtomicMaps + additional entries for mappings
> + or - (depending on how you look at it) all keys in the group will be locked
together, etc, a side-effect of using AtomicMaps
>
> My pref is for approach #2. In terms of implementation, here is what I have in
mind:
>
> * A GroupingInterceptor that intercepts the call early on if the call is a put(K, V,
G) or something similar.
> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in a tx
to ensure atomicity.
> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>
> One of the issues with the API approach is that it heavily pollutes the Cache API.
It will double the number of put() methods on Cache (currently 18 variants of put,
including ones that take in lifespans and maxIdles, async versions that return futures,
etc.) Perhaps this could be in an additional sub-interface interface? GroupedCache? Or
is this degree of method overloading not too confusing?
what about using an Flag-like api?
cache.inGroup("groupName").put(...).
or an "parametrized" flag:
cache.withFlag(Flags.getColocateFlag("grouName").put(...)
as long as we can create "parametrized" flags as bellow, I like the second
approach
Hmm, good idea. I think the builder approach may be the winner here.
>
> Cheers,
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
3:08 p.m.
Another way to do it is by specifying an associator (not my idea TBH [1]).
This is non-intrusive and no-api changes as well.
Cheers.
Mircea
[1] http://coherence.oracle.com/display/COH35UG/Data+Affinity
On 12 Apr 2010, at 15:36, Manik Surtani wrote:
Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there
are a couple of approaches that could be taken:
1. Don't use key.hashcode() as the seed in determining to which nodes an entry is
mapped, but instead on a well-known method or annotated method (e.g., int getGroupID() or
a method annotated with @GroupId). The way I see it, this approach has:
+ Will work, no additional overheads of AtomicMaps
- Cost (reflection)
- Intrusive (what if users have no control over the key class, e.g., String keys?)
2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map, G), etc.
+ Non-intrusive
- Overhead of AtomicMaps + additional entries for mappings
+ or - (depending on how you look at it) all keys in the group will be locked together,
etc, a side-effect of using AtomicMaps
My pref is for approach #2. In terms of implementation, here is what I have in mind:
* A GroupingInterceptor that intercepts the call early on if the call is a put(K, V, G)
or something similar.
* Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in a tx to
ensure atomicity.
* get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
* remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
One of the issues with the API approach is that it heavily pollutes the Cache API. It
will double the number of put() methods on Cache (currently 18 variants of put, including
ones that take in lifespans and maxIdles, async versions that return futures, etc.)
Perhaps this could be in an additional sub-interface interface? GroupedCache? Or is this
degree of method overloading not too confusing?
Cheers,
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:34 p.m.
On 12 Apr 2010, at 14:08, Mircea Markus wrote:
Another way to do it is by specifying an associator (not my idea TBH
[1]).
This is non-intrusive and no-api changes as well.
Is it non-intrusive? Doesn't this mean that keys need to implement an interface?
Cheers.
Mircea
[1] http://coherence.oracle.com/display/COH35UG/Data+Affinity
On 12 Apr 2010, at 15:36, Manik Surtani wrote:
> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a couple of
approaches that could be taken:
>
> 1. Don't use key.hashcode() as the seed in determining to which nodes an entry
is mapped, but instead on a well-known method or annotated method (e.g., int getGroupID()
or a method annotated with @GroupId). The way I see it, this approach has:
>
> + Will work, no additional overheads of AtomicMaps
> - Cost (reflection)
> - Intrusive (what if users have no control over the key class, e.g., String keys?)
>
> 2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map, G),
etc.
>
> + Non-intrusive
> - Overhead of AtomicMaps + additional entries for mappings
> + or - (depending on how you look at it) all keys in the group will be locked
together, etc, a side-effect of using AtomicMaps
>
> My pref is for approach #2. In terms of implementation, here is what I have in
mind:
>
> * A GroupingInterceptor that intercepts the call early on if the call is a put(K, V,
G) or something similar.
> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in a tx
to ensure atomicity.
> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>
> One of the issues with the API approach is that it heavily pollutes the Cache API.
It will double the number of put() methods on Cache (currently 18 variants of put,
including ones that take in lifespans and maxIdles, async versions that return futures,
etc.) Perhaps this could be in an additional sub-interface interface? GroupedCache? Or
is this degree of method overloading not too confusing?
>
> Cheers,
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
3:43 p.m.
On 12 Apr 2010, at 16:34, Manik Surtani wrote:
On 12 Apr 2010, at 14:08, Mircea Markus wrote:
> Another way to do it is by specifying an associator (not my idea TBH [1]).
> This is non-intrusive and no-api changes as well.
Is it non-intrusive? Doesn't this mean that keys need to implement an interface?
[1] describes two approaches. 1st (KeyAssociation) is the intrusive one (corresponds
you 1) ). The second approach discussed in [1] is based on an KeyAssociator and is
non-intrusive.
> Cheers.
> Mircea
>
> [1] http://coherence.oracle.com/display/COH35UG/Data+Affinity
>
> On 12 Apr 2010, at 15:36, Manik Surtani wrote:
>
>> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a couple
of approaches that could be taken:
>>
>> 1. Don't use key.hashcode() as the seed in determining to which nodes an
entry is mapped, but instead on a well-known method or annotated method (e.g., int
getGroupID() or a method annotated with @GroupId). The way I see it, this approach has:
>>
>> + Will work, no additional overheads of AtomicMaps
>> - Cost (reflection)
>> - Intrusive (what if users have no control over the key class, e.g., String
keys?)
>>
>> 2. Additional API methods on the cache - cache.put(K, V, G), cache.putAll(Map,
G), etc.
>>
>> + Non-intrusive
>> - Overhead of AtomicMaps + additional entries for mappings
>> + or - (depending on how you look at it) all keys in the group will be locked
together, etc, a side-effect of using AtomicMaps
>>
>> My pref is for approach #2. In terms of implementation, here is what I have in
mind:
>>
>> * A GroupingInterceptor that intercepts the call early on if the call is a put(K,
V, G) or something similar.
>> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V). Wrapped in
a tx to ensure atomicity.
>> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
>> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
>>
>> One of the issues with the API approach is that it heavily pollutes the Cache
API. It will double the number of put() methods on Cache (currently 18 variants of put,
including ones that take in lifespans and maxIdles, async versions that return futures,
etc.) Perhaps this could be in an additional sub-interface interface? GroupedCache? Or
is this degree of method overloading not too confusing?
>>
>> Cheers,
>> --
>> Manik Surtani
>> manik(a)jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5099
days inactive
5136
days old
infinispan-dev@lists.jboss.org
20 comments
6 participants
participants (6)
-
Brian Stansberry -
Emmanuel Bernard -
Manik Surtani -
Mircea Markus -
Sanne Grinovero -
Vladimir Blagojevic