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 > gal...@redhat.com > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
