Re: [hibernate-dev] HHH-10770
I don't think we ever came back to you on that one. No we have no plan on backporting this feature nor other features in general. Steve wrote a nice piece of why we take a relatively hard stance on older releases https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team It's a bit sad for Spring Boot users but with the pros of such tools comes the curse of lagging behind a bit in versions. We do struggle with these concerns in our own Wildfly and Wildfly Swarm. Emmanuel On Fri 2016-08-05 20:11, Petar Tahchiev wrote: > Hi guys, > > https://hibernate.atlassian.net/browse/HHH-10770 > > has been fixed in Hibernate 5.2.0. However Hibernate 5.2.0 requires Java8 > and there are a lot of projects out there that cannot upgrade to Java8 for > now. Also This is one of the reasons Spring-boot still relies on Hibernate > 5.0.9 for example - because Spring Boot is not Java8 yet. > Do you think you can backport the JCache feature to 5.1. Otherwise we need > to wait one year until next April when Spring5 + Sprinb-boot 2.0 will come > out and support Java8. > > Thank you > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Centralized access to "bootstrap only" resources
I am not sure if that is still relevant but in the past, either HSEARCH or HV were keeping the ReflectionManager around to use it at runtime (either because metadata was loaded lazily or because of a reboot of the factories due to a configuration change. So we need to check that losing access to ReflectionManager after SF is created won't be problematic for these projects. Emmanuel On Sun 2016-08-28 14:34, Steve Ebersole wrote: > We have a number of resources whose references are valid only during > bootstrap. This includes things like: > >- ClassmateContext >- JPA temp ClassLoader >- Scanner and related >- HCANN ReflectionManager (eventually Jandex) >- etc > > The problem is that as currently handled (via > MetadataBuilder/MetadataBuildingOptions) these resources actually are > available at runtime as well, since the MetadataBuildingOptions lives on as > part of the SessionFactory. > > The idea of a "bootstrap only" ServiceRegistry has been discussed a few > times as a way to solve this. That would work, except that it would > potentially get confusing in regards to being sure we are passing the > correct ServiceRegistry all the time IMO. > > Lately I started thinking of an alternative solution: splitting up > MetadataBuildingOptions > into 2 distinct contracts: one with the same idea/scope as now, and another > whose lifecycle is scoped to the bootstrap process. I am tentatively > calling this org.hibernate.boot.spi.BootstrapContext. > > For the most part these changes are isolated internally. Currently I > have MetadataBuilderImpl > building both the MetadataBuildingOptions and this new BootstrapContext. > Some of the applyXYZ calls on MetadataBuilder are now directed to > BootstrapContext instead of the MetadataBuildingOptions. > MetadaBuildingContext was changed to add exposing the BootstrapContext in > addition to the MetadataBuildingOptions. For the most part this works very > well, and like I said is pretty well isolated internally. However, it does > affect any existing usages of those methods removed > from MetadataBuildingOptions. The biggest disconnect there so far is in > JpaIntegrator which tries to access the HCANN ReflectionManager during its > JpaIntegrator#integrate call to process entity callbacks/listeners. With > JPA support being integrated into hibernate-core, we could probably work > around that one by consuming that bit-of-logic into the transformation of > InFlightMetadataCollector -> MetadataImpl. IMO this is a "win" anyway as > it would allow users to leverage JPA entity callbacks/listeners in native > Hibernate apps as well; so this change would not necessarily be a "bad > thing". Another option would be to change the signature of > Integrator#integrate. To be honest it was probably always a mistake to not > use a "parameter object" to pass in to #integrate. > > This also has a tie-in with the 3-phases for TypeConfiguration discussed on > HipChat. To recap, TypeConfiguration (see 6.0 type system design if > unfamiliar with TypeConfiguration) has the following "phases": > >1. TypeConfiguration initialization - this is initialization of the >TypeConfiguration itself. During this phase no "context" is available to >the TypeConfiguration. >2. Metadata building - essentially this is the time spent transitioning >from MetadataSources to Metadata. >3. live SessionFactory - from the point we instantiate the >SessionFactory. > > The first discussion here is exactly how to handle the period from the end > of phase 2 to the beginning of phase 3. Ideally (from an OO encapsulation > perspective) we'd end the second phase after we have built the MetadataImpl > from the InFlight variety. However that leaves a "gap" in terms of the > TypeConfiguration having any context. The other option is to carry the > BootstrapContext along into the MetadataImpl, along into the > SessionFactoryBuilder and to release the BootstrapContext and scope the > TypeConfiguration to the SessionFactory only after the SF is built. So > we'd still not carry that information in the SessionFactory, but we'd keep > it around until the SessionFactory is built. Basically this allows types > and descriptors access to the scoped context (MetadataBuildingContext here > specifically) during that small gap of transitioning from Metadata -> SF. > This is what I propose we do; just want to make sure no one has objections. > > A last part I want to consider is integrations with other Hibernate > projects. Initially I spoke with Gunnar about this a lot in terms of OGM. > I think it is important that we allow the same paradigm we do now for > bootstrapping for the sake of continuity. However I do wonder if, in terms > of integrations, it might also be beneficial to allow an alternate way to > bootstrap as well. Gunnar, back when we developed this you had mentioned a > central "bootstrap delegate builder" contract. That also could fit really > nicely wi
Re: [hibernate-dev] Centralized access to "bootstrap only" resources
On 30 August 2016 at 10:09, Emmanuel Bernard wrote:
> I am not sure if that is still relevant but in the past, either HSEARCH
> or HV were keeping the ReflectionManager around to use it at runtime
> (either because metadata was loaded lazily or because of a reboot of the
> factories due to a configuration change.
>
> So we need to check that losing access to ReflectionManager after SF is
> created won't be problematic for these projects.
In the "dynamic reconfiguration" case we create our own
ReflectionManager instance:
-
https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35
Steve, we had a similar notion of "boot only available components" in
Search but over time we started to have various "special needs" of
various other components holding a reference on these.
When I later tried to re-instate order, it was too late and we got in
arguments like the API's intent not having been clear enough and too
much entanglement had happened.
So while I think it's a good idea, and also Search should try this
again, I think we'd need to design it from day 1 to be defensive
against future code attempting to hold on these services.
Not sure what would be the best approach for ORM, but I guess that
simply invalidating/closing these components after bootstrap and
having these throw an exception after that would be a good start.
However, please allow some flexibility for the case in which someone
really needs one of the services you're dooming at runtime.
For example Search might need to re-read configuration properties at
runtime; we can of course make a copy, but then we'd need a way to be
able to make such a copy (We currently actually make such a copy of
the cfg Properties).
Configuration properties being just an example, maybe we need a
generic way to be able to declare which services should not be cleaned
up after bootstrap?
In practice, the services you've listed should be fine today but the
need for us to make a copy (or to invoke some API to ask for a life
extension) might show up in future.
Rough proposal :
interface BootService {
void flagForUsageBeyondBootstrap();
}
Such an approach would allow you to move many services into this
category quite aggressively, and extension modules beyond core could
request for the services they need for longer retention. Those who
fail to do so, would receive an exception at usage attempt beyond
bootstrap, this would hopefully trigger early awareness of design
issues during development.
Thanks,
Sanne
>
> Emmanuel
>
> On Sun 2016-08-28 14:34, Steve Ebersole wrote:
>> We have a number of resources whose references are valid only during
>> bootstrap. This includes things like:
>>
>>- ClassmateContext
>>- JPA temp ClassLoader
>>- Scanner and related
>>- HCANN ReflectionManager (eventually Jandex)
>>- etc
>>
>> The problem is that as currently handled (via
>> MetadataBuilder/MetadataBuildingOptions) these resources actually are
>> available at runtime as well, since the MetadataBuildingOptions lives on as
>> part of the SessionFactory.
>>
>> The idea of a "bootstrap only" ServiceRegistry has been discussed a few
>> times as a way to solve this. That would work, except that it would
>> potentially get confusing in regards to being sure we are passing the
>> correct ServiceRegistry all the time IMO.
>>
>> Lately I started thinking of an alternative solution: splitting up
>> MetadataBuildingOptions
>> into 2 distinct contracts: one with the same idea/scope as now, and another
>> whose lifecycle is scoped to the bootstrap process. I am tentatively
>> calling this org.hibernate.boot.spi.BootstrapContext.
>>
>> For the most part these changes are isolated internally. Currently I
>> have MetadataBuilderImpl
>> building both the MetadataBuildingOptions and this new BootstrapContext.
>> Some of the applyXYZ calls on MetadataBuilder are now directed to
>> BootstrapContext instead of the MetadataBuildingOptions.
>> MetadaBuildingContext was changed to add exposing the BootstrapContext in
>> addition to the MetadataBuildingOptions. For the most part this works very
>> well, and like I said is pretty well isolated internally. However, it does
>> affect any existing usages of those methods removed
>> from MetadataBuildingOptions. The biggest disconnect there so far is in
>> JpaIntegrator which tries to access the HCANN ReflectionManager during its
>> JpaIntegrator#integrate call to process entity callbacks/listeners. With
>> JPA support being integrated into hibernate-core, we could probably work
>> around that one by consuming that bit-of-logic into the transformation of
>> InFlightMetadataCollector -> MetadataImpl. IMO this is a "win" anyway as
>> it would allow users to leverage JPA entity callbacks/listeners in native
>> Hibernate apps as well; so this change would not necessarily be a "bad
>> thing". Another optio
Re: [hibernate-dev] Centralized access to "bootstrap only" resources
> So we need to check that losing access to ReflectionManager after SF is created won't be problematic for these projects. In HV there is no reference to ReflectionManager whatsoever (same for OGM). 2016-08-30 11:09 GMT+02:00 Emmanuel Bernard : > I am not sure if that is still relevant but in the past, either HSEARCH > or HV were keeping the ReflectionManager around to use it at runtime > (either because metadata was loaded lazily or because of a reboot of the > factories due to a configuration change. > > So we need to check that losing access to ReflectionManager after SF is > created won't be problematic for these projects. > > Emmanuel > > On Sun 2016-08-28 14:34, Steve Ebersole wrote: > > We have a number of resources whose references are valid only during > > bootstrap. This includes things like: > > > >- ClassmateContext > >- JPA temp ClassLoader > >- Scanner and related > >- HCANN ReflectionManager (eventually Jandex) > >- etc > > > > The problem is that as currently handled (via > > MetadataBuilder/MetadataBuildingOptions) these resources actually are > > available at runtime as well, since the MetadataBuildingOptions lives on > as > > part of the SessionFactory. > > > > The idea of a "bootstrap only" ServiceRegistry has been discussed a few > > times as a way to solve this. That would work, except that it would > > potentially get confusing in regards to being sure we are passing the > > correct ServiceRegistry all the time IMO. > > > > Lately I started thinking of an alternative solution: splitting up > > MetadataBuildingOptions > > into 2 distinct contracts: one with the same idea/scope as now, and > another > > whose lifecycle is scoped to the bootstrap process. I am tentatively > > calling this org.hibernate.boot.spi.BootstrapContext. > > > > For the most part these changes are isolated internally. Currently I > > have MetadataBuilderImpl > > building both the MetadataBuildingOptions and this new BootstrapContext. > > Some of the applyXYZ calls on MetadataBuilder are now directed to > > BootstrapContext instead of the MetadataBuildingOptions. > > MetadaBuildingContext was changed to add exposing the BootstrapContext in > > addition to the MetadataBuildingOptions. For the most part this works > very > > well, and like I said is pretty well isolated internally. However, it > does > > affect any existing usages of those methods removed > > from MetadataBuildingOptions. The biggest disconnect there so far is in > > JpaIntegrator which tries to access the HCANN ReflectionManager during > its > > JpaIntegrator#integrate call to process entity callbacks/listeners. With > > JPA support being integrated into hibernate-core, we could probably work > > around that one by consuming that bit-of-logic into the transformation of > > InFlightMetadataCollector -> MetadataImpl. IMO this is a "win" anyway as > > it would allow users to leverage JPA entity callbacks/listeners in native > > Hibernate apps as well; so this change would not necessarily be a "bad > > thing". Another option would be to change the signature of > > Integrator#integrate. To be honest it was probably always a mistake to > not > > use a "parameter object" to pass in to #integrate. > > > > This also has a tie-in with the 3-phases for TypeConfiguration discussed > on > > HipChat. To recap, TypeConfiguration (see 6.0 type system design if > > unfamiliar with TypeConfiguration) has the following "phases": > > > >1. TypeConfiguration initialization - this is initialization of the > >TypeConfiguration itself. During this phase no "context" is > available to > >the TypeConfiguration. > >2. Metadata building - essentially this is the time spent > transitioning > >from MetadataSources to Metadata. > >3. live SessionFactory - from the point we instantiate the > >SessionFactory. > > > > The first discussion here is exactly how to handle the period from the > end > > of phase 2 to the beginning of phase 3. Ideally (from an OO > encapsulation > > perspective) we'd end the second phase after we have built the > MetadataImpl > > from the InFlight variety. However that leaves a "gap" in terms of the > > TypeConfiguration having any context. The other option is to carry the > > BootstrapContext along into the MetadataImpl, along into the > > SessionFactoryBuilder and to release the BootstrapContext and scope the > > TypeConfiguration to the SessionFactory only after the SF is built. So > > we'd still not carry that information in the SessionFactory, but we'd > keep > > it around until the SessionFactory is built. Basically this allows types > > and descriptors access to the scoped context (MetadataBuildingContext > here > > specifically) during that small gap of transitioning from Metadata -> SF. > > This is what I propose we do; just want to make sure no one has > objections. > > > > A last part I want to consider is integrations with other Hibernate > > projects. Initially I spoke
Re: [hibernate-dev] Centralized access to "bootstrap only" resources
On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero wrote: > On 30 August 2016 at 10:09, Emmanuel Bernard > wrote: > > I am not sure if that is still relevant but in the past, either HSEARCH > > or HV were keeping the ReflectionManager around to use it at runtime > > (either because metadata was loaded lazily or because of a reboot of the > > factories due to a configuration change. > > > > So we need to check that losing access to ReflectionManager after SF is > > created won't be problematic for these projects. > > In the "dynamic reconfiguration" case we create our own > ReflectionManager instance: > - > https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35 Interesting that y'all do not specify classloading behavior there (the ClassLoaderDelegate stuff I added to HCANN)... > Steve, we had a similar notion of "boot only available components" in > Search but over time we started to have various "special needs" of > various other components holding a reference on these. > When I later tried to re-instate order, it was too late and we got in > arguments like the API's intent not having been clear enough and too > much entanglement had happened. > Hard to say without specifics. I hate "general rules" :) So let's look at the specifics in terms of things I have moved to BootstrapContext... 1. HCANN ReflectionManager - as you said, y'all create your own for your use case. You'd own the lifecycle of that one you create. I see no conflict there. Also we know that in 7.0 HCANN use will go away and we will move to Jandex. The Jandex IndexView reference is only valid for a limited period of time when WF hands it to us. 2. JPA "temp ClassLoader" - I think this one is self-evident. JPA states that this ClassLoader (if one) is available for only a limited time. 3. ClassmateContext - I centralized this so that we did not have to keep "priming" the classmate caches each time we needed to use classmate. Aside from a possible performance hit, there really is nothing special here versus creating a new ClassmateContext each time you need it. For ORM we currently never use classmate outside of bootstrap. Could that change? Maybe, and we'd deal with that if/when it does. 4. scanning components (ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) - maybe going back to your "dynamic reconfiguration" scenario this makes sense. No idea. But in ORM holding on to these after bootstrap makes no sense. 5. I've also started making BootstrapContext the holder for bootstrap metadata-related collectors. Here we collect SQLFunctions, AuxiliaryDatabaseObjects, AttributeConverterDefinitions, and CacheRegionDefinitions. 6. There are 2 other (new in 6.0) delegates that I keep here too. Interestingly, one is fully intended to be held beyond bootstrap. But I think that these intentions just need to be documented. Overall I'd view a "dynamic reconfiguration" scenario very much like a limite bootstrap scenario. Personally I'd expect to have to maker many of these "boot only resources" available to that process. Not necessarily the same ones as used during the primary bootstrap though. I personally would prefer to not hold reference to these "just in case" we have a "dynamic reconfiguration" situation later; I'd just rebuild them. Granted things like a WF-handed Jandex IndexView would be difficult to handle in there, but that is the case regardless of whether we hold reference to it or not; that has to do with WF eventually invalidating that reference it handed us. So while I think it's a good idea, and also Search should try this > again, I think we'd need to design it from day 1 to be defensive > against future code attempting to hold on these services. > Not sure what would be the best approach for ORM, but I guess that > simply invalidating/closing these components after bootstrap and > having these throw an exception after that would be a good start. > That is roughly what I do. There is a BootstrapContext#release method. It in turn releases the delegates it holds. I can add some defensive checking for throwing some "unavailable" exceptions in case stuff holds references to these. That's a good idea. However, please allow some flexibility for the case in which someone > really needs one of the services you're dooming at runtime. > For example Search might need to re-read configuration properties at > runtime; we can of course make a copy, but then we'd need a way to be > able to make such a copy (We currently actually make such a copy of > the cfg Properties). > Configuration properties being just an example, maybe we need a > generic way to be able to declare which services should not be cleaned > up after bootstrap? > We already hold on to configuration properties into the SF. See Conf
Re: [hibernate-dev] Centralized access to "bootstrap only" resources
Any thoughts on the JpaIntegrator parts of the discussion? Specifically there are 2 main considerations: 1. To change the Integrator#integrate contract - ideally, in retrospect, #integrate probably should have taken a "parameter object" to help insulate from these types of changes. But I wanted to get y'alls thoughts on this especially since this one potentially causes upgrade problems in terms of applications or problems supporting multiple ORM versions in terms of integrations. 2. The alternative I mentioned was to move the JpaIntegrator#integrate functionality in-line with the building of the SessionFactory. This has some really nice benefits as discussed (like JPA callback support from native bootstrapping), but it has some challenges to handle as well mainly in terms of seamlessly combining the different Hibernate event listeners used to implement the native versus JPA behavior. The simple JPA callback/listener case is pretty easy to support regardless. The more difficult ones are event listeners that implement event handling differently () or the ones that cascade different actions depending on native/jpa bootstrapping (). I think even the latter bucket may be easy to handle leveraging SessionFactoryOptions#isJpaBootstrap inside the listeners. The former bucket is really the one I am more concerned with. So let's look at this as 2 distinct questions: 1. Do we want to combine event listeners for native and JPA handling of events? 2. Do we want to change JpaIntegrator#integrate signature to pass its context as a parameter object in order to facilitate this? Or do we in-line the decisions/actions done in JpaIntegrator into SessionFactory init? On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole wrote: > On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero > wrote: > >> On 30 August 2016 at 10:09, Emmanuel Bernard >> wrote: >> > I am not sure if that is still relevant but in the past, either HSEARCH >> > or HV were keeping the ReflectionManager around to use it at runtime >> > (either because metadata was loaded lazily or because of a reboot of the >> > factories due to a configuration change. >> > >> > So we need to check that losing access to ReflectionManager after SF is >> > created won't be problematic for these projects. >> >> In the "dynamic reconfiguration" case we create our own >> ReflectionManager instance: >> - >> https://github.com/hibernate/hibernate-search/blob/fd4acb5d8f396201f5dccc89ba3cbc07becea08a/engine/src/main/java/org/hibernate/search/engine/impl/IncrementalSearchConfiguration.java#L26-L35 > > > Interesting that y'all do not specify classloading behavior there (the > ClassLoaderDelegate stuff I added to HCANN)... > > > >> Steve, we had a similar notion of "boot only available components" in >> Search but over time we started to have various "special needs" of >> various other components holding a reference on these. >> When I later tried to re-instate order, it was too late and we got in >> arguments like the API's intent not having been clear enough and too >> much entanglement had happened. >> > > Hard to say without specifics. I hate "general rules" :) > > So let's look at the specifics in terms of things I have moved to > BootstrapContext... > > >1. HCANN ReflectionManager - as you said, y'all create your own for >your use case. You'd own the lifecycle of that one you create. I see no >conflict there. Also we know that in 7.0 HCANN use will go away and we >will move to Jandex. The Jandex IndexView reference is only valid for a >limited period of time when WF hands it to us. >2. JPA "temp ClassLoader" - I think this one is self-evident. JPA >states that this ClassLoader (if one) is available for only a limited time. >3. ClassmateContext - I centralized this so that we did not have to >keep "priming" the classmate caches each time we needed to use classmate. >Aside from a possible performance hit, there really is nothing special here >versus creating a new ClassmateContext each time you need it. For ORM we >currently never use classmate outside of bootstrap. Could that change? >Maybe, and we'd deal with that if/when it does. >4. scanning components >(ArchiveDescriptorFactory, ScanOptions, ScanEnvironment, Scanner) - maybe >going back to your "dynamic reconfiguration" scenario this makes sense. No >idea. But in ORM holding on to these after bootstrap makes no sense. >5. I've also started making BootstrapContext the holder for bootstrap >metadata-related collectors. Here we collect >SQLFunctions, AuxiliaryDatabaseObjects, AttributeConverterDefinitions, >and CacheRegionDefinitions. >6. There are 2 other (new in 6.0) delegates that I keep here too. >Interestingly, one is fully intended to be held beyond bootstrap. But I >think that these intentions just need to be documented. >
Re: [hibernate-dev] HHH-10478 : OperationContext
Hi Steve, I can start integrating this code into your wip/6.0 branch. Are there any fundamental changes you would like to see before I integrate, or should I integrate as is? Thanks, Gail On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole wrote: > I do like the proposal. Awesome job on the gist. I'll look over the code > over the next few days. > > On Thu, Mar 31, 2016 at 3:05 PM Gail Badner wrote: > >> Replying for consideration for 6.0. >> >> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole >> wrote: >> >>> This is going to have to wait post-5.1 as I mentioned earlier if this >>> was not ready prior to last week. >>> >>> I have just too much on my plate to look at this over 2 days. >>> >>> On Mon, Feb 8, 2016 at 12:29 AM Gail Badner wrote: >>> The POC [1] assumes that we only need a single OperationContext for each type of operation. OperationContextManager has a Map of OperationContext by OperationContextType. Each OperationContext object is lazily created on the first occurence of the corresponding type of operation. Currently, when an operation is initiated (e.g., by Session.merge( entity )), OperationContextManager [2] does the following: - calls ManageableOperationContext#beforeOperation, which puts the OperationContext "in progress"; - executes the operation, which performs cascades according to mappings; - calls ManageableOperationContext#afterOperation, which puts the OperationContext in an invalid state that is "not in progress". When an operation cascades to other entities, the same OperationContext is used. Obviously, OperationContextManager needs to know if an operation is "top-level" (meaning that the operation is on the original entity, and not cascaded). In the POC, if the relevant OperationContext is not in progress at the time that an opeation is initiated, then OperationContextManager assumes that the operation is top-level. If the OperationContext is "in progress", then OperationContextManager assumes that this is a cascaded operation. I am not sure this is always correct. Can anyone think of a case where this could break down? In the POC, the following EventSource methods that contain an argument for the operation cache has been deprecated and is no longer used because the contents of that argument has been moved into an OperationContext: public void merge(String entityName, Object object, Map copiedAlready) public void persist(String entityName, Object object, Map createdAlready) public void persistOnFlush(String entityName, Object object, Map copiedAlready) public void refresh(String entityName, Object object, Map refreshedAlready) public void delete(String entityName, Object child, boolean isCascadeDeleteEnabled, Set transientEntities) Before the POC, it was the above methods that indicated that it was not top-level. If it turns out that having a single OperationContext is not valid, then there needs to be some other way to determine if the operation was top-level. I had originally planned to use PersistenceContext#getCascadeLevel == 0 to indicate an operation was at the top-level, but I found that won't work for some operations. For example, the cascade level for a top-level delete can be > 1 when deleting orphans due to merge or save-or-update operations. Another example is that cascade level is not 0 on top-level save-or-update while flushing. I have some ideas to work around this, but I didn't want to get too far down that path if it wasn't an issue. Thanks, Gail [1] https://github.com/gbadner/hibernate-core/blob/ 3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/ main/java/org/hibernate/engine/operationContext/internal/ OperationContextManager.java [2] https://github.com/gbadner/hibernate-core/blob/ 3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/ main/java/org/hibernate/engine/operationContext/internal/ OperationContextManager.java#L132 On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner wrote: > I've created a gist with an overview of the design: > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a new > section tomorrow about possible shortcomings. > > Here is my POC: > https://github.com/hibernate/hibernate-orm/compare/master.. .gbadner:HHH-10478-OperationContext > . Although no tests fail, the approach may be too simple to model what is > necessary. > > At this point the POC is squashed down to 1 commit: > https://github.com/hibernate/hibernate-orm/commit/ 3d0e2378cb998788b3205afb1e15c443c5ba77e8 > > Have a look and feel free
Re: [hibernate-dev] HHH-10478 : OperationContext
I do wonder if OperationContextType should not be integrated into EventType. I hate repeatng this set of enumerations. Something like https://gist.github.com/sebersole/2a4af882d0a61696dce39d242023add0 Not specific to this PoC but one thing I would also like to see is the ability to know the EventType/OperationContextType we are currently processing (if any). On Tue, Aug 30, 2016 at 3:40 PM Gail Badner wrote: > Hi Steve, > > I can start integrating this code into your wip/6.0 branch. Are there any > fundamental changes you would like to see before I integrate, or should I > integrate as is? > > Thanks, > Gail > > On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole > wrote: > >> I do like the proposal. Awesome job on the gist. I'll look over the >> code over the next few days. >> >> On Thu, Mar 31, 2016 at 3:05 PM Gail Badner wrote: >> >>> Replying for consideration for 6.0. >>> >>> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole >>> wrote: >>> This is going to have to wait post-5.1 as I mentioned earlier if this was not ready prior to last week. I have just too much on my plate to look at this over 2 days. On Mon, Feb 8, 2016 at 12:29 AM Gail Badner wrote: > The POC [1] assumes that we only need a single OperationContext for > each > type of operation. OperationContextManager has a Map of > OperationContext by > OperationContextType. Each OperationContext object is lazily created > on the > first occurence of the corresponding type of operation. > > Currently, when an operation is initiated (e.g., by Session.merge( > entity > )), OperationContextManager [2] does the following: > - calls ManageableOperationContext#beforeOperation, which puts the > OperationContext "in progress"; > - executes the operation, which performs cascades according to > mappings; > - calls ManageableOperationContext#afterOperation, which puts the > OperationContext in an invalid state that is "not in progress". > > When an operation cascades to other entities, the same > OperationContext is > used. > > Obviously, OperationContextManager needs to know if an operation is > "top-level" (meaning that the operation is on the original entity, and > not > cascaded). In the POC, if the relevant OperationContext is not in > progress > at the time that an opeation is initiated, then OperationContextManager > assumes that the operation is top-level. If the OperationContext is "in > progress", then OperationContextManager assumes that this is a cascaded > operation. > > I am not sure this is always correct. Can anyone think of a case where > this > could break down? > > In the POC, the following EventSource methods that contain an argument > for > the operation cache has been deprecated and is no longer used because > the > contents of that argument has been moved into an OperationContext: > > public void merge(String entityName, Object object, Map copiedAlready) > public void persist(String entityName, Object object, Map > createdAlready) > public void persistOnFlush(String entityName, Object object, Map > copiedAlready) > public void refresh(String entityName, Object object, Map > refreshedAlready) > public void delete(String entityName, Object child, boolean > isCascadeDeleteEnabled, Set transientEntities) > > Before the POC, it was the above methods that indicated that it was not > top-level. If it turns out that having a single OperationContext is not > valid, then there needs to be some other way to determine if the > operation > was top-level. > > I had originally planned to use PersistenceContext#getCascadeLevel == > 0 to > indicate an operation was at the top-level, but I found that won't > work for > some operations. For example, the cascade level for a top-level delete > can > be > 1 when deleting orphans due to merge or save-or-update operations. > Another example is that cascade level is not 0 on top-level > save-or-update > while flushing. > > I have some ideas to work around this, but I didn't want to get too far > down that path if it wasn't an issue. > > Thanks, > Gail > > [1] > > https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java > [2] > > https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132 > > > On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner > wrote: > > > I've created a gist with an overview of the design: > > https://gist.github.com/gbadner/f0e635e8fba7b84a
