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?
Thanks,
Sanne
On 9 June 2015 at 13:03, John O'Hara <johara(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev