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