[hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities
johara at redhat.com
Fri Mar 27 06:58:59 EDT 2015
On 26/03/15 16:35, Steve Ebersole wrote:
> Now the "meat"...
> On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne at hibernate.org
> <mailto:sanne at hibernate.org>> wrote:
> What is your primary differentiator between 'SharedEntityEntry' and
> 'StatefulEntityEntry' ?
> For our purposes I'd have used different names, but since there's no
> javadoc yet I wonder if you had different intentions.
> Personally I'd have chosen something like "ImmutableEntityEntry" and
> "MutableEntityEntry", there the Mutable one is a rename of the
> existing implementation, and the Immutable would be a slimmed down
> version which might not need fields such as:
> - loadedState (not needed for readonly)
> - version (what would be the point)
> - ..
> Well I cannot speak for John's reasoning, but knowing his use case I
> think that what you describe is exactly his intent with the split.
> SharedEntityEntry represents an EntityEntry that is immutable and
> needs to be because it is *shared* between Sessions. I personally
> prefer the names mutable and immutable as well. The docs for
> ImmutableEntityEntry should make it clear that it is shared between
> Sessions and that concurrency is the reason it is immutable.
That was my reasoning, but on retrospect, I agree with the
ImmutableEntityEntry and MutableEntityEntry names
> A concern I have is to avoid ever needing to "promote" an
> ImmutableEntityEntry into a MutableEntityEntry: it's easy to mark an
> existing instance of ImmutableEntityEntry as READ_ONLY, but there is
> no going back if the entity entry was initially loaded as READ_ONLY.
> One could think of swapping the existing entityentry, but that could
> get hairy and defeats the point of optimising object allocations.
> Is there a strong guarantee which we can rely on, that if an
> EntityEntry is marked READ_ONLY at first load, noone will ever need to
> re-mark it as mutable?
> If not, the current check in DefaultEntityEntryFactory basing the
> choice on the current status of the Entity might not be enough, we
> might need to be a bit more conservative and only based that on
> getPersister().isMutable() ?
> So there is a distinction here between an immutable entity
> (EntityPersister#isMutable == false) and a entity loaded as read-only
> specific to a Session. The first kind can *never* become
> non-read-only. The second kind can. The first kind should be the only
> case where we use ImmutableEntityEntry, because in the second case
> that entity can later become mutable and as you say we would then need
> to "promote" its corresponding ImmutableEntityEntry to a
> MutableEntityEntry (even more instantiations!).
I was unsure what the best property to test was, I will change to test
johara at redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
More information about the hibernate-dev