Re: [hibernate-dev] HHH-10418 and Infinispan
I see that HHH-11356 is scheduled for 6.0.0.Beta1. Any chance it could be fixed in 5.3? On Thu, Nov 16, 2017 at 10:23 PM, Gail Badner wrote: > Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in > master. [1] > > Maybe it's just the CCE that got fixed. I'll add a comment to HHH-10418 to > clarify that entities and collections still cannot be stored in the same > region in 5.2. > > [1] https://hibernate.atlassian.net/browse/HHH- > 10418?focusedCommentId=83441&page=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-83441 > > On Thu, Nov 16, 2017 at 6:28 PM, Steve Ebersole > wrote: > >> No that is currently broken. See https://hibernate.atlassia >> n.net/browse/HHH-11356 >> >> This won't be fixed in 5.x as fixing it required significant changes to >> the caching SPIs to resolve. >> >> On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: >> >>> Steve/Radim, >>> >>> Is it OK if an entity and collection region have the same name, they >>> will use the same AdvancedCache? I realize that the key will be >>> different (as long as hibernate.cache.keys_factory != simple). >>> >>> I'm assuming they use the same access strategies, etc. I know there >>> would be problems if they didn't (HHH-10707/HHH-11356). >>> >>> I've been looking at how things are implemented in 5.2 to avoid the >>> ClassCacheException when an entity region and collection region has the >>> same name. >>> >>> I see that org.hibernate.internal.CacheImpl has a separate map for each >>> type of cache (i.e., entity, collection, natural-id). [1] >>> >>> I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# >>> buildEntityRegion and #buildCollectionRegion both call #getCache. [2] >>> >>> #getCache checks to see if there is already a cache with the specified >>> regionName, but does not take the type (i.e., entity, collection, >>> natural-id) into account. If there is already a cache with that region >>> name, it will be used. >>> >>> In other words, it seems that if an entity and collection region have >>> the same name, they will use the same AdvancedCache. >>> >>> I just want to confirm that this is intended and there is no problem >>> with having different types of data in the same AdvancedCache. >>> >>> Thanks, >>> Gail >>> >>> [1] https://github.com/hibernate/hibernate-orm/blob/master/ >>> hibernate-core/src/main/java/org/hibernate/internal/ >>> CacheImpl.java#L59-L61 >>> [2] https://github.com/hibernate/hibernate-orm/blob/master/ >>> hibernate-infinispan/src/main/java/org/hibernate/cache/ >>> infinispan/InfinispanRegionFactory.java#L680-L729 >>> >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-10418 and Infinispan
Oh, OK. There's a comment that made it sound like HHH-10418 was fixed in master. [1] Maybe it's just the CCE that got fixed. I'll add a comment to HHH-10418 to clarify that entities and collections still cannot be stored in the same region in 5.2. [1] https://hibernate.atlassian.net/browse/HHH-10418?focusedCommentId=83441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-83441 On Thu, Nov 16, 2017 at 6:28 PM, Steve Ebersole wrote: > No that is currently broken. See https://hibernate. > atlassian.net/browse/HHH-11356 > > This won't be fixed in 5.x as fixing it required significant changes to > the caching SPIs to resolve. > > On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: > >> Steve/Radim, >> >> Is it OK if an entity and collection region have the same name, they will >> use the same AdvancedCache? I realize that the key will be different (as >> long as hibernate.cache.keys_factory != simple). >> >> I'm assuming they use the same access strategies, etc. I know there would >> be problems if they didn't (HHH-10707/HHH-11356). >> >> I've been looking at how things are implemented in 5.2 to avoid the >> ClassCacheException when an entity region and collection region has the >> same name. >> >> I see that org.hibernate.internal.CacheImpl has a separate map for each >> type of cache (i.e., entity, collection, natural-id). [1] >> >> I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# >> buildEntityRegion and #buildCollectionRegion both call #getCache. [2] >> >> #getCache checks to see if there is already a cache with the specified >> regionName, but does not take the type (i.e., entity, collection, >> natural-id) into account. If there is already a cache with that region >> name, it will be used. >> >> In other words, it seems that if an entity and collection region have the >> same name, they will use the same AdvancedCache. >> >> I just want to confirm that this is intended and there is no problem with >> having different types of data in the same AdvancedCache. >> >> Thanks, >> Gail >> >> [1] https://github.com/hibernate/hibernate-orm/blob/ >> master/hibernate-core/src/main/java/org/hibernate/ >> internal/CacheImpl.java#L59-L61 >> [2] https://github.com/hibernate/hibernate-orm/blob/ >> master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/ >> InfinispanRegionFactory.java#L680-L729 >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-10418 and Infinispan
No that is currently broken. See https://hibernate.atlassian.net/browse/HHH-11356 This won't be fixed in 5.x as fixing it required significant changes to the caching SPIs to resolve. On Thu, Nov 16, 2017 at 8:10 PM Gail Badner wrote: > Steve/Radim, > > Is it OK if an entity and collection region have the same name, they will > use the same AdvancedCache? I realize that the key will be different (as > long as hibernate.cache.keys_factory != simple). > > I'm assuming they use the same access strategies, etc. I know there would > be problems if they didn't (HHH-10707/HHH-11356). > > I've been looking at how things are implemented in 5.2 to avoid the > ClassCacheException when an entity region and collection region has the > same name. > > I see that org.hibernate.internal.CacheImpl has a separate map for each > type of cache (i.e., entity, collection, natural-id). [1] > > I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# > buildEntityRegion and #buildCollectionRegion both call #getCache. [2] > > #getCache checks to see if there is already a cache with the specified > regionName, but does not take the type (i.e., entity, collection, > natural-id) into account. If there is already a cache with that region > name, it will be used. > > In other words, it seems that if an entity and collection region have the > same name, they will use the same AdvancedCache. > > I just want to confirm that this is intended and there is no problem with > having different types of data in the same AdvancedCache. > > Thanks, > Gail > > [1] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/CacheImpl.java#L59-L61 > [2] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L680-L729 > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HHH-10418 and Infinispan
Steve/Radim, Is it OK if an entity and collection region have the same name, they will use the same AdvancedCache? I realize that the key will be different (as long as hibernate.cache.keys_factory != simple). I'm assuming they use the same access strategies, etc. I know there would be problems if they didn't (HHH-10707/HHH-11356). I've been looking at how things are implemented in 5.2 to avoid the ClassCacheException when an entity region and collection region has the same name. I see that org.hibernate.internal.CacheImpl has a separate map for each type of cache (i.e., entity, collection, natural-id). [1] I also see that org.hibernate.cache.infinispan.InfinispanRegionFactory# buildEntityRegion and #buildCollectionRegion both call #getCache. [2] #getCache checks to see if there is already a cache with the specified regionName, but does not take the type (i.e., entity, collection, natural-id) into account. If there is already a cache with that region name, it will be used. In other words, it seems that if an entity and collection region have the same name, they will use the same AdvancedCache. I just want to confirm that this is intended and there is no problem with having different types of data in the same AdvancedCache. Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/internal/CacheImpl.java#L59-L61 [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L680-L729 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] JPA Compliance
When I said multiple modes, I was thinking of defining all these situations In some interface which declares methods like: boolean throwsExceptionWhenClosingAClosedEMF() The interface can have two implementations for Strict JPA and Native mode. However, the setting could take the FQN of the interface implementation, so a user can define those compatibility methods according to their needs. E.g. Maybe someone wants the Strict JPA mode but with just 2 differences; - don't throw exception when closing the ENG twice - use the native Hibernate FlushMode.AUTO instead of the JPA one. Vlad On 16 Nov 2017 10:49 pm, "Steve Ebersole" wrote: > There is already a similar setting, although specific to query language: > `hibernate.query.jpaql_strict_compliance` - so there is precedence for > such a solution. > > I'm not sure about the "with multiple modes" aspect though. What are > these other enumerated mode values? > > > On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea > wrote: > >> Where the JPA way is questionable, let's add one configuration: >> hibernate.jpa.compliance with multiple modes: >> >> - strict: we do whatever the JPA standard says we should do, like >> throwing an exception when trying to close the EMF twice >> - native: we bend the rule where we don't agree with the standard >> >> Maybe we should expose all those cases and group them in some interface >> to allow the user to customize the level of compliance they need. >> >> Vlad >> >> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole >> wrote: >> >>> It was added deprecated. Meaning I added it knowing it would go away >>> and I wanted to avoid users using it. >>> >>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >>> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >>> >>> Its specifically the "where the JPA way is questionable" aspect I am >>> asking about. Like to me, it really never makes sense to throw an >>> exception when I close something that is already closed. So how do we >>> handle cases like this? >>> >>> >>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea >>> wrote: >>> Hi Steve, I think that for 5.2 was ok to have the isJpaBootstrap method to avoid breaking compatibility for the native bootstrap. For 6.0, maybe it's easier if we just align to the JPA spec where it makes sense, and only provide a separation where the JPA way is questionable. I noticed that the isJpaBootstrap method is deprecated. Was it intended to be removed in 6.0? Vlad On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole wrote: > Part of 5.2 was merging the JPA contracts into the corresponding > Hibernate > ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of > EntityManagerFactory - instead, SessionFactory now extends > EntityManagerFactory. > > This caused a few problems that we handled as they came up. In > working on > the JPA 2.2 compatibility testing, I see that there are a few more > still > that we need to resolve. Mostly they relate to JPA expecting > exceptions in > certain cases where Hibernate has historically been lenient. E.g., JPA > says that calling EntityManagerFactory#close on an EMF that is already > closed should result in an exception. Historically, calling > SessionFactory#close on a SF that is already closed is simply ignored. > Philosophical debates aside[1], we need to decide how we want to handle > this situation such that we can throw the JPA-expected exceptions when > needed. Do we simply change SF#close to match the JPA expectation? > Or do > we somehow > make SF#close aware of JPA versus "native" use? This latter option > was the > intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly > continue to use that as the basis of the solution here for other cases. > > This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. > So if > the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, > that flag is set to true. It's an ok solution, but it does have some > limitations - mainly, there was previously a distinction between > SF#close > being called versus EMF#close being called (they were different > classes, so > they could react differently). Therefore, regardless of bootstrap > mechanism, if the user unwrapped the EMF to a SF, they would always > get the > legacy SF behavior. > > So long story short, so we want to consider an alternative approach to > deciding what to do in "some"[2] of these cases? Again, we clearly > need > these to throw the spec-mandated exceptions in certain "strict > compliance" > situations. The question really is how to do that. Should we: > >1. just completely change the behavior to align with the spec? >2. change the behavior
Re: [hibernate-dev] JPA Compliance
There is already a similar setting, although specific to query language: `hibernate.query.jpaql_strict_compliance` - so there is precedence for such a solution. I'm not sure about the "with multiple modes" aspect though. What are these other enumerated mode values? On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea wrote: > Where the JPA way is questionable, let's add one configuration: > hibernate.jpa.compliance with multiple modes: > > - strict: we do whatever the JPA standard says we should do, like throwing > an exception when trying to close the EMF twice > - native: we bend the rule where we don't agree with the standard > > Maybe we should expose all those cases and group them in some interface to > allow the user to customize the level of compliance they need. > > Vlad > > On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole > wrote: > >> It was added deprecated. Meaning I added it knowing it would go away and >> I wanted to avoid users using it. >> >> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA >> 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. >> >> Its specifically the "where the JPA way is questionable" aspect I am >> asking about. Like to me, it really never makes sense to throw an >> exception when I close something that is already closed. So how do we >> handle cases like this? >> >> >> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea >> wrote: >> >>> Hi Steve, >>> >>> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid >>> breaking compatibility for the native bootstrap. >>> For 6.0, maybe it's easier if we just align to the JPA spec where it >>> makes sense, >>> and only provide a separation where the JPA way is questionable. >>> >>> I noticed that the isJpaBootstrap method is deprecated. Was it intended >>> to be removed in 6.0? >>> >>> Vlad >>> >>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >>> wrote: >>> Part of 5.2 was merging the JPA contracts into the corresponding Hibernate ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of EntityManagerFactory - instead, SessionFactory now extends EntityManagerFactory. This caused a few problems that we handled as they came up. In working on the JPA 2.2 compatibility testing, I see that there are a few more still that we need to resolve. Mostly they relate to JPA expecting exceptions in certain cases where Hibernate has historically been lenient. E.g., JPA says that calling EntityManagerFactory#close on an EMF that is already closed should result in an exception. Historically, calling SessionFactory#close on a SF that is already closed is simply ignored. Philosophical debates aside[1], we need to decide how we want to handle this situation such that we can throw the JPA-expected exceptions when needed. Do we simply change SF#close to match the JPA expectation? Or do we somehow make SF#close aware of JPA versus "native" use? This latter option was the intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly continue to use that as the basis of the solution here for other cases. This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, that flag is set to true. It's an ok solution, but it does have some limitations - mainly, there was previously a distinction between SF#close being called versus EMF#close being called (they were different classes, so they could react differently). Therefore, regardless of bootstrap mechanism, if the user unwrapped the EMF to a SF, they would always get the legacy SF behavior. So long story short, so we want to consider an alternative approach to deciding what to do in "some"[2] of these cases? Again, we clearly need these to throw the spec-mandated exceptions in certain "strict compliance" situations. The question really is how to do that. Should we: 1. just completely change the behavior to align with the spec? 2. change the behavior to match the spec *conditionally*, where that condition could be: 1. `#isJpaBootstrap` 2. some setting 3. some extension contract 4. something else? >>> >>> Thoughts? [1] It's not relevant e.g. that I think JPA is wrong here. We need to comply with the spec, at least in certain cases ;) [2] I say "some" here, because I think the spec is correct in some cases - for example, I think its clearly correct that a closed EMF throws an exception when `#createEntityManager` is called. Personally I think its questionable whether closing an already closed EMF should be an exception. >>> ___ hibernat
Re: [hibernate-dev] JPA Compliance
Where the JPA way is questionable, let's add one configuration: hibernate.jpa.compliance with multiple modes: - strict: we do whatever the JPA standard says we should do, like throwing an exception when trying to close the EMF twice - native: we bend the rule where we don't agree with the standard Maybe we should expose all those cases and group them in some interface to allow the user to customize the level of compliance they need. Vlad On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole wrote: > It was added deprecated. Meaning I added it knowing it would go away and > I wanted to avoid users using it. > > BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA > 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. > > Its specifically the "where the JPA way is questionable" aspect I am > asking about. Like to me, it really never makes sense to throw an > exception when I close something that is already closed. So how do we > handle cases like this? > > > On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea > wrote: > >> Hi Steve, >> >> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid >> breaking compatibility for the native bootstrap. >> For 6.0, maybe it's easier if we just align to the JPA spec where it >> makes sense, >> and only provide a separation where the JPA way is questionable. >> >> I noticed that the isJpaBootstrap method is deprecated. Was it intended >> to be removed in 6.0? >> >> Vlad >> >> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole >> wrote: >> >>> Part of 5.2 was merging the JPA contracts into the corresponding >>> Hibernate >>> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >>> EntityManagerFactory - instead, SessionFactory now extends >>> EntityManagerFactory. >>> >>> This caused a few problems that we handled as they came up. In working >>> on >>> the JPA 2.2 compatibility testing, I see that there are a few more still >>> that we need to resolve. Mostly they relate to JPA expecting exceptions >>> in >>> certain cases where Hibernate has historically been lenient. E.g., JPA >>> says that calling EntityManagerFactory#close on an EMF that is already >>> closed should result in an exception. Historically, calling >>> SessionFactory#close on a SF that is already closed is simply ignored. >>> Philosophical debates aside[1], we need to decide how we want to handle >>> this situation such that we can throw the JPA-expected exceptions when >>> needed. Do we simply change SF#close to match the JPA expectation? Or >>> do >>> we somehow >>> make SF#close aware of JPA versus "native" use? This latter option was >>> the >>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >>> continue to use that as the basis of the solution here for other cases. >>> >>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >>> if >>> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >>> that flag is set to true. It's an ok solution, but it does have some >>> limitations - mainly, there was previously a distinction between SF#close >>> being called versus EMF#close being called (they were different classes, >>> so >>> they could react differently). Therefore, regardless of bootstrap >>> mechanism, if the user unwrapped the EMF to a SF, they would always get >>> the >>> legacy SF behavior. >>> >>> So long story short, so we want to consider an alternative approach to >>> deciding what to do in "some"[2] of these cases? Again, we clearly need >>> these to throw the spec-mandated exceptions in certain "strict >>> compliance" >>> situations. The question really is how to do that. Should we: >>> >>>1. just completely change the behavior to align with the spec? >>>2. change the behavior to match the spec *conditionally*, where that >>>condition could be: >>> 1. `#isJpaBootstrap` >>> 2. some setting >>> 3. some extension contract >>> 4. something else? >> >> >>> >>> Thoughts? >>> >>> >>> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >>> comply with the spec, at least in certain cases ;) >>> >>> [2] I say "some" here, because I think the spec is correct in some cases >>> - >>> for example, I think its clearly correct that a closed EMF throws an >>> exception when `#createEntityManager` is called. Personally I think its >>> questionable whether closing an already closed EMF should be an >>> exception. >>> >> ___ >>> 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] JPA Compliance
It was added deprecated. Meaning I added it knowing it would go away and I wanted to avoid users using it. BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. Its specifically the "where the JPA way is questionable" aspect I am asking about. Like to me, it really never makes sense to throw an exception when I close something that is already closed. So how do we handle cases like this? On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea wrote: > Hi Steve, > > I think that for 5.2 was ok to have the isJpaBootstrap method to avoid > breaking compatibility for the native bootstrap. > For 6.0, maybe it's easier if we just align to the JPA spec where it makes > sense, > and only provide a separation where the JPA way is questionable. > > I noticed that the isJpaBootstrap method is deprecated. Was it intended > to be removed in 6.0? > > Vlad > > On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole > wrote: > >> Part of 5.2 was merging the JPA contracts into the corresponding Hibernate >> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >> EntityManagerFactory - instead, SessionFactory now extends >> EntityManagerFactory. >> >> This caused a few problems that we handled as they came up. In working on >> the JPA 2.2 compatibility testing, I see that there are a few more still >> that we need to resolve. Mostly they relate to JPA expecting exceptions >> in >> certain cases where Hibernate has historically been lenient. E.g., JPA >> says that calling EntityManagerFactory#close on an EMF that is already >> closed should result in an exception. Historically, calling >> SessionFactory#close on a SF that is already closed is simply ignored. >> Philosophical debates aside[1], we need to decide how we want to handle >> this situation such that we can throw the JPA-expected exceptions when >> needed. Do we simply change SF#close to match the JPA expectation? Or do >> we somehow >> make SF#close aware of JPA versus "native" use? This latter option was >> the >> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >> continue to use that as the basis of the solution here for other cases. >> >> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >> if >> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >> that flag is set to true. It's an ok solution, but it does have some >> limitations - mainly, there was previously a distinction between SF#close >> being called versus EMF#close being called (they were different classes, >> so >> they could react differently). Therefore, regardless of bootstrap >> mechanism, if the user unwrapped the EMF to a SF, they would always get >> the >> legacy SF behavior. >> >> So long story short, so we want to consider an alternative approach to >> deciding what to do in "some"[2] of these cases? Again, we clearly need >> these to throw the spec-mandated exceptions in certain "strict compliance" >> situations. The question really is how to do that. Should we: >> >>1. just completely change the behavior to align with the spec? >>2. change the behavior to match the spec *conditionally*, where that >>condition could be: >> 1. `#isJpaBootstrap` >> 2. some setting >> 3. some extension contract >> 4. something else? > > >> >> Thoughts? >> >> >> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >> comply with the spec, at least in certain cases ;) >> >> [2] I say "some" here, because I think the spec is correct in some cases - >> for example, I think its clearly correct that a closed EMF throws an >> exception when `#createEntityManager` is called. Personally I think its >> questionable whether closing an already closed EMF should be an exception. >> > ___ >> 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] JPA Compliance
Hi Steve, I think that for 5.2 was ok to have the isJpaBootstrap method to avoid breaking compatibility for the native bootstrap. For 6.0, maybe it's easier if we just align to the JPA spec where it makes sense, and only provide a separation where the JPA way is questionable. I noticed that the isJpaBootstrap method is deprecated. Was it intended to be removed in 6.0? Vlad On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole wrote: > Part of 5.2 was merging the JPA contracts into the corresponding Hibernate > ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of > EntityManagerFactory - instead, SessionFactory now extends > EntityManagerFactory. > > This caused a few problems that we handled as they came up. In working on > the JPA 2.2 compatibility testing, I see that there are a few more still > that we need to resolve. Mostly they relate to JPA expecting exceptions in > certain cases where Hibernate has historically been lenient. E.g., JPA > says that calling EntityManagerFactory#close on an EMF that is already > closed should result in an exception. Historically, calling > SessionFactory#close on a SF that is already closed is simply ignored. > Philosophical debates aside[1], we need to decide how we want to handle > this situation such that we can throw the JPA-expected exceptions when > needed. Do we simply change SF#close to match the JPA expectation? Or do > we somehow > make SF#close aware of JPA versus "native" use? This latter option was the > intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly > continue to use that as the basis of the solution here for other cases. > > This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if > the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, > that flag is set to true. It's an ok solution, but it does have some > limitations - mainly, there was previously a distinction between SF#close > being called versus EMF#close being called (they were different classes, so > they could react differently). Therefore, regardless of bootstrap > mechanism, if the user unwrapped the EMF to a SF, they would always get the > legacy SF behavior. > > So long story short, so we want to consider an alternative approach to > deciding what to do in "some"[2] of these cases? Again, we clearly need > these to throw the spec-mandated exceptions in certain "strict compliance" > situations. The question really is how to do that. Should we: > >1. just completely change the behavior to align with the spec? >2. change the behavior to match the spec *conditionally*, where that >condition could be: > 1. `#isJpaBootstrap` > 2. some setting > 3. some extension contract > 4. something else? > > Thoughts? > > > [1] It's not relevant e.g. that I think JPA is wrong here. We need to > comply with the spec, at least in certain cases ;) > > [2] I say "some" here, because I think the spec is correct in some cases - > for example, I think its clearly correct that a closed EMF throws an > exception when `#createEntityManager` is called. Personally I think its > questionable whether closing an already closed EMF should be an exception. > ___ > 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
[hibernate-dev] JPA Compliance
Part of 5.2 was merging the JPA contracts into the corresponding Hibernate ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of EntityManagerFactory - instead, SessionFactory now extends EntityManagerFactory. This caused a few problems that we handled as they came up. In working on the JPA 2.2 compatibility testing, I see that there are a few more still that we need to resolve. Mostly they relate to JPA expecting exceptions in certain cases where Hibernate has historically been lenient. E.g., JPA says that calling EntityManagerFactory#close on an EMF that is already closed should result in an exception. Historically, calling SessionFactory#close on a SF that is already closed is simply ignored. Philosophical debates aside[1], we need to decide how we want to handle this situation such that we can throw the JPA-expected exceptions when needed. Do we simply change SF#close to match the JPA expectation? Or do we somehow make SF#close aware of JPA versus "native" use? This latter option was the intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly continue to use that as the basis of the solution here for other cases. This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So if the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, that flag is set to true. It's an ok solution, but it does have some limitations - mainly, there was previously a distinction between SF#close being called versus EMF#close being called (they were different classes, so they could react differently). Therefore, regardless of bootstrap mechanism, if the user unwrapped the EMF to a SF, they would always get the legacy SF behavior. So long story short, so we want to consider an alternative approach to deciding what to do in "some"[2] of these cases? Again, we clearly need these to throw the spec-mandated exceptions in certain "strict compliance" situations. The question really is how to do that. Should we: 1. just completely change the behavior to align with the spec? 2. change the behavior to match the spec *conditionally*, where that condition could be: 1. `#isJpaBootstrap` 2. some setting 3. some extension contract 4. something else? Thoughts? [1] It's not relevant e.g. that I think JPA is wrong here. We need to comply with the spec, at least in certain cases ;) [2] I say "some" here, because I think the spec is correct in some cases - for example, I think its clearly correct that a closed EMF throws an exception when `#createEntityManager` is called. Personally I think its questionable whether closing an already closed EMF should be an exception. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
