On 26/03/15 16:35, Steve Ebersole wrote: > Now the "meat"... > > On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero <sa...@hibernate.org > <mailto:sa...@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 joh...@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). _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
