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

[Radim Vansa]

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).

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?

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.

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