On Apr 8, 2013, at 1:46 PM, Sanne Grinovero <sa...@infinispan.org> wrote:
> I fail to understand the purpose of the feature then. What prevents me > to use the existing code today just storing some extra fields in my > custom values? ^ Nothing, this is doable. > What do we get by adding this code? ^ You avoid the need of the wrapper since we already have a wrapper internally, which is ICE. ICEs can already keep versions around, why do I need a wrapper class that stores a version for Hot Rod server? Down the line, we could decide to leave the metadata around to better support use cases like this: https://issues.jboss.org/browse/ISPN-506 https://community.jboss.org/wiki/VersioningDesignDocument - The tombstones that Max refers to could potentially be tombstone ICEs with only metadata info. Cheers, > > Sanne > > On 8 April 2013 12:40, Galder Zamarreño <gal...@redhat.com> wrote: >> >> On Apr 8, 2013, at 1:26 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> >>> On 8 April 2013 12:06, Galder Zamarreño <gal...@redhat.com> wrote: >>>> >>>> On Apr 8, 2013, at 12:56 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 8 April 2013 11:44, 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 >>>>> >>>>> 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? >>>>> >>>>> Why is getExternalizer() awkward for unmarshalling? >>>> >>>> ^ Because you don't have an instance yet, so what's the Externalizer for >>>> it? IOW, there's no much point to doing that, simply register it depending >>>> on your desire: >>>> https://docs.jboss.org/author/display/ISPN/Plugging+Infinispan+With+User+Defined+Externalizers >>> >>> That's what I would expect. >>> >>>> >>>>> I would expect you to have the marshaller already known during >>>>> deserialization. >>>> >>>> You would, as long as you follow the instructions in >>>> https://docs.jboss.org/author/display/ISPN/Plugging+Infinispan+With+User+Defined+Externalizers >>>> >>>>> Agreed that extensing Serializable is not a good idea. >>>>> >>>>> Are you thinking about the impact on CacheStore(s) and state transfer? >>>> >>>> ^ What about it in particular? >>>> >>>>> Eviction of no longer used metadata ? >>>> >>>> ^ Since the metadata is part of the entry, it'd initially go when the >>>> entry is evicted. We might wanna leave it around in some cases… but it'd >>>> be for other use cases. >>> >>> I thought the plan was to have entries refer to the metadata, but that >>> different entries sharing the same metadata would point to the same >>> instance. >> >> ^ Could be, but most likely not. >> >>> So this metadata needs to be stored separately in the CacheStore, >>> preloaded as appropriate, transferred during state transfer, >>> passivated when convenient and cleaned up when no longer referred to. >> >> ^ Well, it's part of the internal cache entry, so it'd be treated just like >> ICE. >> >>> Am I wrong? Seems you plan to store a copy of the metadata within each ICE. >> >> ^ The idea is to store it alongside right now, but maybe at some point it >> might make sense to leave it around (i.e. for 2LC use case), but this won't >> be done yet. >> >>> >>> >>>> >>>> I'm also considering separating the serialization/marshalling concerns >>>> from the defensive copying concerns. IOW, add a copy() method to the >>>> Metadata interface, or have a separate interface for those externally >>>> provided objects that require to be defensive copied. IOW, do something >>>> like what Scala Case Classes do with their copy() method, but without the >>>> issues of clone… I need to investigate this further to come up with a nice >>>> solution. >>>> >>>> One positive side to splitting both concerns is speed. A Metadata >>>> implementation might have ways to make a copy of itself which are more >>>> efficient than marshalling/unmarshalling. >>>> >>>> Thoughts? >>>> >>>>> >>>>> Sanne >>>>> >>>>> >>>>> Any other ideas? >>>>> >>>>>> >>>>>> 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 >> >> >> -- >> 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
