On Mon, Apr 8, 2013 at 2:36 PM, Galder Zamarreño <gal...@redhat.com> wrote:
> > On Apr 8, 2013, at 1:11 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > > > > > > > > > On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño <gal...@redhat.com> > wrote: > > > > On Apr 8, 2013, at 12:35 PM, Galder Zamarreño <gal...@redhat.com> wrote: > > > > > > > > On Apr 8, 2013, at 11:17 AM, Manik Surtani <msurt...@redhat.com> > wrote: > > > > > >> 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. > > > > > > ^ Excellent point, it could be a nightmare if users could change the > metadata reference by the ICE at will. I'll have a think on how to best > achieve this. > > > > ^ The metadata is gonna have to be marshalled somehow to ship to other > nodes, so that could be a way to achieve it, by enforcing this somehow. > When the cache receives it, it can marshaller/unmarshall it to make a copy > > > > > > If Metadata is just an interface, nothing is stopping the user from > implementing maxIdle() to return Random.maxLong(). Besides, local caches > need to support Metadata as well, and we shouldn't force > serialization/deserialization for local caches. > > > > So I think we'd be better off documenting that Metadata objects should > not change after they are inserted in the cache, just like keys and values. > > > > > > One way would be to make Metadata extend Serializable, but not keen on > that. Another would be to somehow force the interface to define the > Externalizer to use (i.e. an interface method like getExternalizer()), but > that's akward when it comes to unmarshalling… what about forcing the > Metadata object to be provided with a @SerializeWith annotation? > > > > Any other ideas? > > > > > > Why force anything? I think Metadata instances should be treated just > like keys and values, so they should be able to use Externalizers (via > @SerializeWith), Serializable, or Externalizable, depending on the user's > requirements. > > ^ I agree. > > What do you think of my suggestion in the other email to separate both > concerns and somehow enforce a copy of the object to be provided instead? > > I wrote my reply before I saw your other email :) Having said that, I still think enforcing a copy doesn't make sense (see my other comment). > > > > > > > > > > Cheers, > > > > > >> > > >> On 8 Apr 2013, at 09:24, Galder Zamarreño <gal...@redhat.com> 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 > > >>> gal...@redhat.com > > >>> twitter.com/galderz > > >>> > > >>> Project Lead, Escalante > > >>> http://escalante.io > > >>> > > >>> Engineer, Infinispan > > >>> http://infinispan.org > > >>> > > >>> > > >>> _______________________________________________ > > >>> infinispan-dev mailing list > > >>> infinispan-dev@lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > >> > > >> -- > > >> Manik Surtani > > >> ma...@jboss.org > > >> twitter.com/maniksurtani > > >> > > >> Platform Architect, JBoss Data Grid > > >> http://red.ht/data-grid > > >> > > >> > > >> _______________________________________________ > > >> infinispan-dev mailing list > > >> infinispan-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > > -- > > > Galder Zamarreño > > > gal...@redhat.com > > > twitter.com/galderz > > > > > > Project Lead, Escalante > > > http://escalante.io > > > > > > Engineer, Infinispan > > > http://infinispan.org > > > > > > > > > -- > > Galder Zamarreño > > gal...@redhat.com > > twitter.com/galderz > > > > Project Lead, Escalante > > http://escalante.io > > > > Engineer, Infinispan > > http://infinispan.org > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev