On Mar 20, 2013, at 11:25 AM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
Why would you need to *store* anything which is equal for all
entries?
^ It's not, necessarily. lifespan/maxIdle can be different for each entry. Version is
most likely different per entry.
I'd have an interceptor "decorate" stuff with some
constant additions;
otherwise you could also think of reusing instances, like I had
suggested a while back to change the Externalizer contract to allow it
to be passed some context to make unique objects taking them from a
pool.
At least it looks like you would have to split such metadata: version
for example needs to be maintained per entry, as will be vector
clocks.
^ I think Tristan confused things a little bit here. It's at the ICE level where
metadata will be stored, as is already currently.
Sanne
On 20 March 2013 11:04, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
> On 03/20/2013 11:51 AM, Manik Surtani wrote:
>> On 18 Mar 2013, at 12:21, Galder Zamarreño <galder(a)redhat.com> wrote:
>>
>>> IOW, you'll be able to say: create an Infinsipan Server that has String
as key and value of type X, where X is the actual data type, no metadata!! The metadata
(version, encoding, whatever is requried to fulfill the compatibility reqs in ISPN-2281)
will be passed as part of the put/replace…etc (I will email this around when in place).
>> Not sure I get this. Where will this metadata be stored?
> Metadata should be moved to the ICE-level, or the Cache-level (for
> metadata common to all entries in the cache, to save space: e.g. if all
> entries in my cache are text/plain)
>
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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