[hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

[Steve Ebersole]

Now the "meat"...

On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <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.



> 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!).