[infinispan-dev] Cache Java 8 API proposal - First draft

[Galder Zamarreño]

Thanks Radim for the great feedback, comments inline:

> On 13 Mar 2015, at 10:20, Radim Vansa <rvansa at redhat.com> wrote:
> 
> Q1: What about versions? I really like the approach taken for 
> conditional operations in RemoteCache, because versions (as opposed to 
> replace(key, old, new)) get rid of ABA problems, wouldn't have problems 
> in return values after operation retry during topology change, reduce 
> overhead of sending big old values etc... The functional API luckily 
> allows 'any' operation, but this seems to me as such an useful 
> functionality that we should not force users implementing versions in 
> their values (unless they want to); versions should be part of Metadata 
> (at least I hope so - see CacheEntry vs. Metadata thread). Since this 
> API should be the most comprehensive one on which we'll build even more 
> complicated data structures than atomic counters, I somehow lack the 
> access to Metadata there (though I understand that you didn't want to 
> bloat it).

^ `Value` class will expose metadata and versioning information somehow, but as said in the proposal, there are still some things that need to be added.

Exposing version of the existing entry to the functions is crucial because one of the problems I'm trying to find a good solution for is [1] (see also slides in [2] that I prepared for Berlin). The problem there is that existing replace() is only atomic when comparing objects by equality, and the `eval` method design will allow you to customize that comparison the way you want, and in fact for Hot Rod, we'd compare using version information. E.g. here's how it could work (TBD!):

CompletableFuture<Boolean> replaced = functionalCache.eval("e", v -> {
   if (v.version().equals(userProvidedVersion)) return true;
   else return false;
});

[1] https://issues.jboss.org/browse/ISPN-4972
[2] https://dl.dropboxusercontent.com/u/6148072/berlin-2015-galder-versionedreplace.pdf

> Q2: For performance, I would expect that a (replicated?) cache for 
> well-known/registered lambdas could be useful. Then, you'd need the 
> functional API with direct lambda IDs - you don't want to do the map 
> lookup every time. Or any other ideas? I think you said that you 
> benchmarked the serialization overhead, can you present the numbers?

I've pinged David, JBoss Marshalling creator, to get some tips about this and I also plan to check with other Java 8 gurus such as Mario, but from what I can understand, there's three parts to a lambda: 

- the lambda function class instance itself
- the parameters you pass in to the lambda
- any objects captured/referenced by the lambda

I think the lambda functions can be cached but of course, the parameters nor captured objects can't. When we create Map/ConcurrentMap/JCache decorators, we'll control the decorator contents and we'd have the chance to do whatever caching we need. I don't think we even need to replicate them at all since the classes themselves will cache the functions.

So, that would leave parameters and captured/referenced objects to be serialized since that's the variable part. Not sure if these two can be serialized independently. Parameters maybe but captured objects might be tough.

I've not done benchmarking yet.

> Q3: Do you expect that in non-tx mode the primary will replicate to 
> backup the lambda, or full value? With non-trivial lambdas, after node 
> crash when the backups have different values, this can lead to forever 
> diverging values. But yes, this could be chosen with a flag.

You'd replicate the lambda (or if you can cache it, then somehow avoid sending all its info), along with parameters, and any capture values. So, for `Map.put` implementation function you are replicating, it includes the full value.

If you're trying to store a data structure and and non-tx, there's indeed a chance of having partially applied updates. We'd need some merging here possibly...

Cheers,

> 
> Radim
> 
> On 03/13/2015 09:10 AM, Galder Zamarreño wrote:
>> Hi all,
>> 
>> We're starting to work on some prototypes for the Java 8 API coming up in Infinispan 8.
>> 
>> I've written a design wiki for a replacement of our main embedded Cache interface that takes advantage of Java 8 improvements:
>> https://github.com/infinispan/infinispan/wiki/Java-8-API-proposal
>> 
>> It'd be great to hear your thoughts.
>> 
>> Proposals for Java 8 versions for cache manager, remote cache and other external APIs are yet TBD.
>> 
>> Regards,
>> --
>> Galder Zamarreño
>> galder at redhat.com
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com