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

Now the "meat"... On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sanne(a)hibernate.org <mailto:sanne@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!).