On Apr 8, 2013, at 12:35 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Apr 8, 2013, at 11:17 AM, Manik Surtani <msurtani(a)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?
Any other ideas?
Cheers,
>
> On 8 Apr 2013, at 09:24, Galder Zamarreño <galder(a)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/a35956fe291d2b2dc3b7fa7bf44d...
>> [2]
https://github.com/galderz/infinispan/commit/a35956fe291d2b2dc3b7fa7bf44d...
>> --
>> Galder Zamarreño
>> galder(a)redhat.com
>>
twitter.com/galderz
>>
>> Project Lead, Escalante
>>
http://escalante.io
>>
>> Engineer, Infinispan
>>
http://infinispan.org
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
>
http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org