[infinispan-dev] CacheEntry vs. Metadata

[Galder Zamarreño]

Hi Radim,

See responses inline.

> On 27 Feb 2015, at 15:49, Radim Vansa <rvansa at redhat.com> wrote:
> 
> Hi,
> 
> I was already several times looking on the class hierarchy of CacheEntry 
> and its descendants. Since the documentation of those interfaces is 
> usually a one liner, I'd like to ask for the big picture:
> 
> So we have CacheEntry, which implements MetadataAware - therefore, it 
> contains a metadata, which define lifespan, maxIdle time and version. 
> However, even the CacheEntry interface itself contains getters for 
> lifespan and idle time and MortalCacheEntry hosts the fields - so I see 
> that there's some duplication with the Metadata object.

Originally, there was only CacheEntry, we added MetadataAware later on.

To avoid causing too much havoc, we decided to leave existing CacheEntry methods in there.

> Beyond the expiration-related stuff (and common key - value getters), 
> CacheEntry has several methods querying and manipulating its state - 
> isChanged, isValid, isRemoved etc. It's a bit confusing that this is 
> presented not as a single state but rather a matrix of boolean states. 

^ I agree.

> When I've tried to implement EntryProcessor several weeks ago (I've 
> stopped the attempts since this should be implemented in Infinispan 8), 
> I had quite a hard time figuring out which should be set and how in case 
> I want to update/remove the entry. undelete() and skipLookup() are not 
> obvious, either.

^ Right, we've not made any changes to it because with Java 8, we'd want a way to manipulate the entry in a much saner way.

> Is the reason for having Immortal/Mortal/Transient/TransientMortal 
> entries + Metadata* versions + *Values to optimally use memory?

Hmmm, the different subclasses were created to try to make sure only the data relevant to the use case is maintained as much as possible and avoid empty fields.

> Then there are the ReadCommitted and RepeatableRead entries - are these 
> ever stored in data container, or just in context? What's the exact 
> relation between those implementing InternalCacheEntry and MVCCEntry?

RC and RR are wrappers that provide RC and RR guaranteees :)

No, they're not stored as such in the DC. They're only use for guarantees.

> Then there's the DeltaAwareCacheEntry - this does not fit to the image 
> for me at all.

^ Not sure about that one, I guess it's for handling delta aware entries?

> I am also not sure about the relation of EmbeddedMetadata and 
> InternalMetadataImpl

When metadata layer was added, I created EmbeddedMetadata as implementation.

InternalMetadataImpl appears to have been created by Mircea when reworking persistence layer, so he possibly created it to have it persisted. Nor its name nor its intention seems clear either.

NOTE:

Cache entry and metadata will be even more important in Java 8 API because this will be what we expose to the eval functions and users can manipulate it to do execute all sorts of functions. Cache entry and/or metadata will most likely be revamped into new interfaces (as already hinted by the prototype), so I'd not worry too much about changing what we have now, but make sure that we'll have fits properly. 

Thanks for the questions and feedback :)

Cheers,

> 
> Thanks for your insight!
> 
> Radim
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
> 
> _______________________________________________
> 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