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

I had been working on the assumption that the entity is mutable/immutable. Is it possible for EntityEntry to be immutable? e.g. is it valid for states such as BooleanState.IS_BEING_REPLICATED or BooleanState.LOADED_WITH_LAZY_PROPERTIES_UNFETCHED to change during the lifetime of the EntityEntry

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

The only distinction we care about is EntityPetsister#isMutable. The read-only case should be handled by the normal MutableEntityEntry. In other words there is nothing to pass to EntityPersister to make a decision based on; just getEntityEntryBuilder (). As far as LockMode, I think it makes the

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

On 27/03/15 12:14, Sanne Grinovero wrote: > Also from OGM and Search perspective, we're not expecting any of this > to be backported. > It's not a functional blocker, "just" significant performance improvements. > > How do we move further? John, I'm not familiar with the requirements > for the by

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

Also from OGM and Search perspective, we're not expecting any of this to be backported. It's not a functional blocker, "just" significant performance improvements. How do we move further? John, I'm not familiar with the requirements for the bytecode instrumentation, but can help a bit on the other

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

Steve, From our point of view, we would not be looking to backport any features introduced to any of the ORM4 releases. Our focus has shifted to the next major release of EAP as we have a number of issues we need to overcome. Getting this feature into ORM5 sooner rather than later is essentia

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

BTW, if we go this route this *cannot* be backported because we do allow users to override EntityPersister; its an extension point. Adding a new method to extension points in bugfixes is a no-no. On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole wrote: > An EntityPersister describes each entity y

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

An EntityPersister describes each entity you defined in your model. Its one-to-one between @Entity and EntityPersister. And really, it is totally reasonable to have the EntityPersister determine the "EntityEntry builder" to use. That also eliminates needing to develop yet-another-extension-point

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

On 26/03/15 16:22, Steve Ebersole wrote: > The contract I suggested btw is missing one use case I know we have > discussed in regards to OGM a few times... the ability to store > references to datastore specific locators (I think the use case was to > efficiently load collections through that da

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

On 26/03/15 16:35, Steve Ebersole wrote: > Now the "meat"... > > On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero > wrote: > > > What is your primary differentiator between 'SharedEntityEntry' and > 'StatefulEntityEntry' ? > For our purposes I'd have used d

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

On 26/03/15 15:20, Sanne Grinovero wrote: > [adding the mailing list] > > Generally speaking, looks like we agree on the direction: EntityEntry > needs to be an interface, and some clever logic to select the > appropriate implementations. > In your draft you're having a single EntityEntryFactory as

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

Now the "meat"... On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero 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 intenti

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

The contract I suggested btw is missing one use case I know we have discussed in regards to OGM a few times... the ability to store references to datastore specific locators (I think the use case was to efficiently load collections through that datastore reference). But that (obviously) requires p

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

Apparently I hit some key combo that means send :) To finish up... On Thu, Mar 26, 2015 at 10:58 AM, Steve Ebersole wrote: > > On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero > wrote: >> >> >> Concurrency >>Since the goal is to share the ImmutableEntityEntry instance among >> multiple th

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

On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero wrote: > > > Concurrency >Since the goal is to share the ImmutableEntityEntry instance among > multiple threads reading it, I'd rather make sure that it is really > immutable. For example it now holds onto potentially lazy initialized > fields,

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

Thanks for your thoughts Sanne. I am going to break my responses down into digestable chunks to follow... On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero wrote: > [adding the mailing list] > > Generally speaking, looks like we agree on the direction: EntityEntry > needs to be an interface, a

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

[adding the mailing list] Generally speaking, looks like we agree on the direction: EntityEntry needs to be an interface, and some clever logic to select the appropriate implementations. In your draft you're having a single EntityEntryFactory as a global service; I'm wondering if we shouldn't have