[infinispan-dev] AdvancedCache.put with Metadata parameter

[Sanne Grinovero]

On 8 April 2013 11:44, Galder Zamarreño <galder at redhat.com> wrote:

>
> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño <galder at redhat.com> wrote:
>
> >
> > On Apr 8, 2013, at 11:17 AM, Manik Surtani <msurtani at 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? I would expect you to
have the marshaller already known during deserialization.
Agreed that extensing Serializable is not a good idea.

Are you thinking about the impact on CacheStore(s) and state transfer?
Eviction of no longer used metadata ?

Sanne


>
> Any other ideas?
>
> >
> > Cheers,
> >
> >>
> >> On 8 Apr 2013, at 09:24, Galder Zamarreño <galder at 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
> >>> galder at redhat.com
> >>> twitter.com/galderz
> >>>
> >>> Project Lead, Escalante
> >>> http://escalante.io
> >>>
> >>> Engineer, Infinispan
> >>> http://infinispan.org
> >>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> --
> >> Manik Surtani
> >> manik at jboss.org
> >> twitter.com/maniksurtani
> >>
> >> Platform Architect, JBoss Data Grid
> >> http://red.ht/data-grid
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > --
> > Galder Zamarreño
> > galder at redhat.com
> > twitter.com/galderz
> >
> > Project Lead, Escalante
> > http://escalante.io
> >
> > Engineer, Infinispan
> > http://infinispan.org
> >
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130408/e4903105/attachment.html