[infinispan-dev] Distributed execution framework - API proposal(s)

[Vladimir Blagojevic]

On 11-01-03 6:16 AM, Galder Zamarreño wrote:
> Maybe I'm reading this wrong but are you saying that multiple caches cause problem with mapping of task units to nodes in cluster?
>
> Or are you just doing it not to clutter the API?

Clutter of API. If you did not like K,V,T,R imagine dealing with 
multiple cache confusion! It would be horrible.

> I think DistributedTaskContext extending CacheContainer is rather confusing, particularly when DistributedTaskContext has K,V parameters that generally are associated with Cache rather than CacheContainer.

Yes, true but DistributedTaskContext is primarily geared towards one 
cache while providing opportunity to read data from other caches as 
well. Hence K,V for the primary cache. Any suggestions how to deal with 
this in a more elegant way? Maybe pass DistributedTaskContext and 
CacheContainer as separate parameters?


> Also, why is a context iterable? Iterates the contents of a CacheContainer? extends generally means that "is something". AFAIK, you'd be able to iterate a Map or Cache, but not a CacheContainer.

True.

> Personally, I think DistributedTask has too many generics (K, V, T, R) and it's hard to read. IMO, only T and R should only exist. I would also try to stick to Callable conventions that takes a V.
>
> I don't like to see things like this, reminds me of EJB 2.1 where you were forced to implement a method to simply get hold of a ctx. There're much nicer ways to do things like this, if completely necessary (see EJB3) :

You mean injection? There is a proposal 2 that essentially does this.

>        @Override
>        public void mapped(DistributedTaskContext<String, String>  ctx) {
>           this.ctx = ctx;
>        }
>
> Looking at the example provided, it seems to me that all DistributedTaskContext is used for is to navigate the Cache contents from a user defined callable, in which case I would limit its scope.

What do you mean - "limit its scope"?