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

[John O'Hara]

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 
on getPersister().isMutable()

Thanks

john


-- 
John O'Hara
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).