All sounds very good. One important thing to consider is that the reference to Metadata passed in by the client app will be tied to the ICE for the entire lifespan of the ICE. You'll need to think about a defensive copy or some other form of making the Metadata immutable (by the user application, at least) the moment it is passed in.
On 8 Apr 2013, at 09:24, Galder Zamarreño <[email protected]> wrote: > Hi all, > > As mentioned in > http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012348.html, in > paralell to the switch to Equivalent* collections, I was also working on > being able to pass metadata into Infinispan caches. This is done to better > support the ability to store custom metadata in Infinispan without the need > of extra wrappers. So, the idea is that InternalCacheEntry instances will > have a a reference to this Metadata. > > One of that metadata is version, which I've been using as test bed to see if > clients could pass succesfully version information via metadata. As you > already know, Hot Rod requires to store version information. Before, this was > stored in a class called CacheValue alongside the value itself, but the work > I've done in [1], this is passed via the new API I've added in [2]. > > So, I'd like to get some thoughts on this new API. I hope that with these new > put/replace versions, we can get rid of the nightmare which is all the other > put/replace calls taking lifespan and/or maxIdle information. In the end, I > think there should be two basic puts: > > - put(K, V) > - put(K, V, Metadata) > > And their equivalents. > > IMPORTANT NOTE 1: The implementation details are bound to change, because the > entire Metadata needs to be stored in InternalCacheEntry, not just version, > lifespan..etc. I'll further develop the implementation once I get into adding > more metadata, i.e. when working on interoperability with REST. So, don't pay > too much attention to the implementation itself, focus on the AdvancedCache > API itself and let's refine that. > > IMPORTANT NOTE 2: The interoperability work in commit in [1] is WIP, so > please let's avoid discussing it in this email thread. Once I have a more > final version I'll send an email about it. > > Apart from working on enhancements to the API, I'm now carry on tackling the > interoperability work with aim to have an initial version of the Embedded <-> > Hot Rod interoperability as first step. Once that's in, it can be released to > get early feedback while the rest of interoperability modes are developed. > > Cheers, > > [1] > https://github.com/galderz/infinispan/commit/a35956fe291d2b2dc3b7fa7bf44d8965ffb1a54d > [2] > https://github.com/galderz/infinispan/commit/a35956fe291d2b2dc3b7fa7bf44d8965ffb1a54d#L10R313 > -- > Galder Zamarreño > [email protected] > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
