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

Eduardo Martins emmartins at gmail.com
Mon Jan 3 14:30:10 EST 2011


Why not?

public interface DistributedTaskContext {
		
   <K, V> Cache<K, V> getCache(String cacheName);
		
   Address getExecutionNode();
		
}

-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco

On Mon, Jan 3, 2011 at 11:37 AM, Vladimir Blagojevic
<vblagoje at redhat.com> wrote:
> 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"?
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



More information about the infinispan-dev mailing list