Re: [infinispan-dev] CacheEntry vs. Metadata
Hi Radim,
See responses inline.
On 27 Feb 2015, at 15:49, Radim Vansa <rvansa(a)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(a)redhat.com>
JBoss Performance Team
_______________________________________________
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