[hibernate-dev] HHH-9857 - Reuse of EntityEntry for bytecode enhanced read-only reference cached entities

[Steve Ebersole]

Sanne, the phrase ImmutableEntityEntry was meant to convey that it is the
entry corresponding to an immutable entity.  Maybe something like
NonUpdateableEntityEntry would be better.  At any rate the javadocs need to
be redone there.  The javadocs on ImmutableEntityEntry were left there from
when it was just one class.  Those need to be moved to the contract.  The
javadocs for ImmutableEntityEntry should discuss all that we have discussed
here.

Unfortunately making EntityEntry itself completely immutable is at direct
odds with its entire purpose for existence.  It is meant to hold the state
for the entity in regards to its association with the PC.

Now, that said, in the case of non-mutable entities much of that state is
irrelevant.  As far as status, non-mutable entities are always considered
READ_ONLY, aside from the cases or creating or deleting them.  And I guess
loading them too.  Personally I would vote that we simply override more of
the methods here:

1) setStatus - make sure the incoming status is "allowed" much like we do
for lockmode
2) postUpdate - throw exception
3) setReadOnly - only allow readOnly==true and just set status





On Tue, Jun 9, 2015 at 9:35 AM John O'Hara <johara at redhat.com> wrote:

> On 09/06/15 15:30, Sanne Grinovero wrote:
> > On 9 June 2015 at 13:50, John O'Hara <johara at redhat.com> wrote:
> >> On 09/06/15 13:14, Sanne Grinovero wrote:
> >>> There are lots of setters on EntityEntry, but sharing it would require
> >>> at least the implementation to be fully immutable to be threadsafe.
> >>>
> >>> I see three options for the custom EntityEntry implementation:
> >>>    - simply ignore any write method by implementing each method as a
> no-op
> >>>    - throw exceptions on any write method
> >>>    - split the EntityEntry interface into a parent interface
> >>> "ReadOnlyEntityEntry" which doesn't have any such method
> >>>
> >>> The first option seems the easy way out but we would not notice any
> >>> unintended / illegal usage; I'd prefer the third one but I'm not sure
> >>> which impact it would have, seems like a large change that needs
> >>> experimenting.
> >>>
> >>> I just noticed an ImmutableEntityEntry implementation exists now, but
> >>> it's not actually immutable? That should be fixed, at very least the
> >>> javadoc to explain what that class purpose is?
> >> Yes, an ImmutableEntityEntry instance will be created for the
> EntityEntry in
> >> our use case (e.g. when this would be a performance benefit), so we can
> test
> >> for instanceof ImmutableEntityEntry or add no-ops for write operations
> for
> >> this implementation.
> >>
> >> The object isn't immutable as the state field changes during the
> lifetime of
> >> the object. This question was asked by Steve, i.e. whether it was the
> Entity
> >> that was immutable or the EntityEntry that was immutable, I thought I
> had
> >> replied with my thoughts but I can not find my response to that
> question.
> >> Should clarify this in the javadoc. I think that ImmutbaleEntityEntry
> should
> >> refer to the Entity being immutable.
> > Possibly, but then you can't reuse the same instance across multiple
> Session(s).
> > If your goal is to completely avoid allocating new instances of
> > ImmutbaleEntityEntry, you have to make it really immutable, or play
> > with synchronized and volatiles.. wouldn't we be adding a worse
> > problem in that case? I guess we could try and measure, but if we can
> > find a way to make it completely immutable that would be easier.
> Yes, the goal would be to avoid allocating new instances and reusing
> across sessions. I think synchronization would be v. expensive in this
> area of code. My instinct would be try and make ImmutbaleEntityEntry
> immutable to ensure thread safety, but would need to think about current
> state changes e.g. the status field changing LOADING->READ_ONLY
>
> > Sanne
> >
> >> Thanks,
> >>
> >> John
> >>
> >>> Thanks,
> >>> Sanne
> >>>
> >>> On 9 June 2015 at 13:03, John O'Hara <johara at redhat.com> wrote:
> >>>> For our use case, bytecode enhanced reference cached immutable
> entities,
> >>>> our top object for memory allocation is EntityEntry.
> >>>>
> >>>> We see an EntityEntry object created every time an immutable entity is
> >>>> added to a persistence context.
> >>>>
> >>>> In our use case, where we know the entity is immutable and we already
> >>>> have an EntityEntry cached, can we re-use the EntityEntry between
> >>>> sessions? This would reduce the allocation rate of EntityEntry in our
> >>>> use case by ~50%.
> >>>>
> >>>>
> >>>> --
> >>>> 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).
> >>>>
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >> --
> >> 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).
> >>
>
>
> --
> 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).
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>