Re: [hibernate-dev] 5.3.0 release tomorrow
I would suggest a Beta2, as we were hoping to still do some work on it. No strong take though, as far as I know our pending work is optional / low impact: A. produce the feature packs in ORM B. test OGM integration Status of these: A# The feature packs have low impact on ORM's risk and quality, although it would be nice to be able to test the feature packs "as released" from ORM within Search and OGM. It requires a second Gradle plugin; Andrea created a first POC last week, but we still need some work on it, release it and then have the ORM build use it. Finally we'll need to update the documentation and guides to explain to users how to consume it. B# The OGM integration is a bit late; we should be able to verify it next week. We didn't start converting OGM into feature packs; that would take even longer but I guess we can regard this one as optional. All of this could be done in a CR1 if you see reasons to accelerate, I'd just suggest a preference for a little more time. Thanks, Sanne On 30 January 2018 at 22:00, Steve Ebersole wrote: > Wanted to remind everyone that tomorrow is the next time-boxed release for > 5.3. > > I wanted to get everyone's opinions about the version number, whether this > should be Beta2 or CR1. IMO It depends how you view the remaining > challenges with the JPA TCK, with CR1 being the optimistic view. > ___ > 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] 5.3.0 release tomorrow
having a Beta2 release is fine also to me On 31 January 2018 at 10:26, Sanne Grinovero wrote: > I would suggest a Beta2, as we were hoping to still do some work on > it. No strong take though, as far as I know our pending work is > optional / low impact: > A. produce the feature packs in ORM > B. test OGM integration > > Status of these: > > A# > The feature packs have low impact on ORM's risk and quality, although > it would be nice to be able to test the feature packs "as released" > from ORM within Search and OGM. > It requires a second Gradle plugin; Andrea created a first POC last > week, but we still need some work on it, release it and then have the > ORM build use it. > Finally we'll need to update the documentation and guides to explain > to users how to consume it. > > B# > The OGM integration is a bit late; we should be able to verify it next > week. We didn't start converting OGM into feature packs; that would > take even longer but I guess we can regard this one as optional. > > All of this could be done in a CR1 if you see reasons to accelerate, > I'd just suggest a preference for a little more time. > > Thanks, > Sanne > > > On 30 January 2018 at 22:00, Steve Ebersole wrote: > > Wanted to remind everyone that tomorrow is the next time-boxed release > for > > 5.3. > > > > I wanted to get everyone's opinions about the version number, whether > this > > should be Beta2 or CR1. IMO It depends how you view the remaining > > challenges with the JPA TCK, with CR1 being the optimistic view. > > ___ > > 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Minor changes to the website
Hi, Just so you know, I just made a few minor changes to the website: - in the Releases dymanic submenu, you now have a label stating "latest stable"/"development" to make it clearer what the versions are (it's especially useful at this point of the ORM development for instance as 5.3 is the latest but not yet considered stable) - I made the Documentation entry menu of ORM dynamic with a submenu following the same principles as for Releases. It avoids going to the latest then using the dropdown at the top (I kept the dropdown anyway) In passing, I also added a placeholder page for the ORM 5.3 doc stating it will be available soon. HTH -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Minor changes to the website
Sounds great, thanks! On 31 January 2018 at 12:15, Guillaume Smet wrote: > Hi, > > Just so you know, I just made a few minor changes to the website: > - in the Releases dymanic submenu, you now have a label stating "latest > stable"/"development" to make it clearer what the versions are (it's > especially useful at this point of the ORM development for instance as 5.3 > is the latest but not yet considered stable) > - I made the Documentation entry menu of ORM dynamic with a submenu > following the same principles as for Releases. It avoids going to the > latest then using the dropdown at the top (I kept the dropdown anyway) > > In passing, I also added a placeholder page for the ORM 5.3 doc stating it > will be available soon. > > HTH > > -- > Guillaume > ___ > 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] Minor changes to the website
Looks great! Thanks On Wed, Jan 31, 2018 at 8:18 AM Sanne Grinovero wrote: > Sounds great, thanks! > > On 31 January 2018 at 12:15, Guillaume Smet > wrote: > > Hi, > > > > Just so you know, I just made a few minor changes to the website: > > - in the Releases dymanic submenu, you now have a label stating "latest > > stable"/"development" to make it clearer what the versions are (it's > > especially useful at this point of the ORM development for instance as > 5.3 > > is the latest but not yet considered stable) > > - I made the Documentation entry menu of ORM dynamic with a submenu > > following the same principles as for Releases. It avoids going to the > > latest then using the dropdown at the top (I kept the dropdown anyway) > > > > In passing, I also added a placeholder page for the ORM 5.3 doc stating > it > > will be available soon. > > > > HTH > > > > -- > > Guillaume > > ___ > > 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3.0 release tomorrow
I have no strong preference either way. On 01/30/2018 05:00 PM, Steve Ebersole wrote: > Wanted to remind everyone that tomorrow is the next time-boxed release for > 5.3. > > I wanted to get everyone's opinions about the version number, whether this > should be Beta2 or CR1. IMO It depends how you view the remaining > challenges with the JPA TCK, with CR1 being the optimistic view. > ___ > 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] 5.3.0 release tomorrow
I would say let's go for Beta2. We are not in a hurry considering the challenges still pending so no need to rush in the CR phase. On the NoORM side: - Search - Yoann has prepared a PR with the 5.3 support so we should be OK on this side. 5.9 will be tagged early next week and we'll release an alpha of 5.10 for OGM consumption. - OGM - Davide is going to release OGM 5.2 (still with ORM 5.1) early next week, then we will merge the ORM 5.2 support that is pending for quite some time (the PR is ready, just waiting for the 5.2 release) and we will experiment with the 5.3 support on top of that. I don't expect many issues as it's not a step as big as 5.1 -> 5.2. So you can expect some feedback from us in the next 2 weeks. On Wed, Jan 31, 2018 at 4:11 PM, Chris Cranford wrote: > I have no strong preference either way. > > On 01/30/2018 05:00 PM, Steve Ebersole wrote: > > Wanted to remind everyone that tomorrow is the next time-boxed release > for > > 5.3. > > > > I wanted to get everyone's opinions about the version number, whether > this > > should be Beta2 or CR1. IMO It depends how you view the remaining > > challenges with the JPA TCK, with CR1 being the optimistic view. > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class
Didn't we discuss this at our last meeting? The general opinion - and final verdict - was that doing like you're asking now again would be way too much work and not generally worth it, not least not in the best interest of all our users. Technically it's certainly possible, but a lot of work going at cost of more useful progress, not least possibly causing confusion to users in various ways. Our proposal is unchanged (from the meeting): we'll have - experimentally - two versions in WildFly. In a first stage this would be version 5.1 and 5.3, so that people needing backwards compatibility with 5.1 can use 5.1 (can't have better compatibility than that!), while people wanting to use a later version can opt in for that. In a second stage, possibly onboarding some lessons, version 5.3 will be gradually replaced with 6.0. MAYBE 6.0 will be API compatible with 5.3, but definitely not with 5.1. I'm not sure if we can have this in WildFly.next, but the sooner the better. As soon as we have a stable release of Hibernate ORM 5.3 we'll start looking into details of such a double integration. Thanks, Sanne On 31 January 2018 at 06:43, Scott Marlow wrote: > WildFly would like to have a version of 5.3+, that is compatible with ORM > 5.1, with regard to the org.hibernate.session changes (including mapping of > exceptions thrown, so that the same exceptions are thrown). > > Is it even possible to have an extra org.hibernate.Session interface + impl > (bridge) that matches the same session included in 5.1? The impl would > delegate to the real underlying org.hibernate.Session impl classes and also > wrap thrown exceptions, so that Hibernate 5.1 native ORM apps, continue to > work without code changes > > Or something like that. > > I could see how some users wouldn't want to use the compatibility layer to > avoid extra overhead, so in WildFly, we would have to make that possible > also. > > What do you think? > > We would need something similar in ORM 6.0+ that is also compatible with > 5.1, if this is possible. > > Scott > ___ > 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] 5.3.0 release tomorrow
The next time-box is in fact 2 weeks... :) Hopefully we have these JPA TCK challenges resolved by then and can do CR then. So yes, please have feedback by then. Yoann and I have been working on Search and ORM 5.3 (at least parts) so I think that will work out fine. But yes, OGM makes me a little nervous as as far as I know we have no idea about that integration yet On Wed, Jan 31, 2018 at 9:22 AM Guillaume Smet wrote: > I would say let's go for Beta2. We are not in a hurry considering the > challenges still pending so no need to rush in the CR phase. > > On the NoORM side: > - Search - Yoann has prepared a PR with the 5.3 support so we should be OK > on this side. 5.9 will be tagged early next week and we'll release an alpha > of 5.10 for OGM consumption. > - OGM - Davide is going to release OGM 5.2 (still with ORM 5.1) early next > week, then we will merge the ORM 5.2 support that is pending for quite some > time (the PR is ready, just waiting for the 5.2 release) and we will > experiment with the 5.3 support on top of that. I don't expect many issues > as it's not a step as big as 5.1 -> 5.2. > > So you can expect some feedback from us in the next 2 weeks. > > On Wed, Jan 31, 2018 at 4:11 PM, Chris Cranford > wrote: > >> I have no strong preference either way. >> >> On 01/30/2018 05:00 PM, Steve Ebersole wrote: >> > Wanted to remind everyone that tomorrow is the next time-boxed release >> for >> > 5.3. >> > >> > I wanted to get everyone's opinions about the version number, whether >> this >> > should be Beta2 or CR1. IMO It depends how you view the remaining >> > challenges with the JPA TCK, with CR1 being the optimistic view. >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class
Not to mention, I'm really not even sure what this request "means". As we all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory and Session/EntityManager, and that caused us to have to make changes to certain method signatures - most notably `Session#getFlushMode` was one of the problems. Session defined that returning a FlushMode; however JPA also defined this same method, although poorly named IMO since it instead returns JPA's FlushModeType (so why the method is not called `#getFlushModeType` is beyond me. Anyway the point is that there is no way to rectify these - there is no way that we can define a contract that simultaneously conforms to both. As Sanne said, and as we all agreed during f2f, the best approach is to have both versions available for use. On Wed, Jan 31, 2018 at 9:28 AM Sanne Grinovero wrote: > Didn't we discuss this at our last meeting? > > The general opinion - and final verdict - was that doing like you're > asking now again would be way too much work and not generally worth > it, not least not in the best interest of all our users. Technically > it's certainly possible, but a lot of work going at cost of more > useful progress, not least possibly causing confusion to users in > various ways. > > Our proposal is unchanged (from the meeting): > > we'll have - experimentally - two versions in WildFly. > > In a first stage this would be version 5.1 and 5.3, so that people > needing backwards compatibility with 5.1 can use 5.1 (can't have > better compatibility than that!), while people wanting to use a later > version can opt in for that. > > In a second stage, possibly onboarding some lessons, version 5.3 will > be gradually replaced with 6.0. MAYBE 6.0 will be API compatible with > 5.3, but definitely not with 5.1. > > I'm not sure if we can have this in WildFly.next, but the sooner the > better. As soon as we have a stable release of Hibernate ORM 5.3 we'll > start looking into details of such a double integration. > > Thanks, > Sanne > > > > > On 31 January 2018 at 06:43, Scott Marlow wrote: > > WildFly would like to have a version of 5.3+, that is compatible with ORM > > 5.1, with regard to the org.hibernate.session changes (including mapping > of > > exceptions thrown, so that the same exceptions are thrown). > > > > Is it even possible to have an extra org.hibernate.Session interface + > impl > > (bridge) that matches the same session included in 5.1? The impl would > > delegate to the real underlying org.hibernate.Session impl classes and > also > > wrap thrown exceptions, so that Hibernate 5.1 native ORM apps, continue > to > > work without code changes > > > > Or something like that. > > > > I could see how some users wouldn't want to use the compatibility layer > to > > avoid extra overhead, so in WildFly, we would have to make that possible > > also. > > > > What do you think? > > > > We would need something similar in ORM 6.0+ that is also compatible with > > 5.1, if this is possible. > > > > Scott > > ___ > > 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3.0 release tomorrow
On Wed, Jan 31, 2018 at 4:42 PM, Steve Ebersole wrote: > The next time-box is in fact 2 weeks... :) > > But yes, OGM makes me a little nervous as as far as I know we have no idea > about that integration yet > We discussed it on Tuesday at our meeting. I think we can commit to getting your feedback on OGM in the next 2 weeks. Personally, I would like to have an OGM release supporting ORM 5.3 not long ago after the ORM 5.3 release, even if we don't have any new features. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3.0 release tomorrow
Yes, I agree. As it is, it is very likely that in 2 weeks we will have ORM 5.3.0.CR1. So even if you did do a OGM release at that time we are going to be limited in what exactly we can change if we find changes are needed. Interestingly this goes back to earlier discussions about "release early/often" for the purpose of identifying regressions. Granted there y'all were talking about 5.2, but the same happens here from the ORM perspective in 5.3. We need to not be dragging version non-stable releases out as we continue to wait for +1's from all integrators (Search, OGM, Spring, etc). Anyway, we'll hear what we hear in 2 weeks. On Wed, Jan 31, 2018 at 9:49 AM Guillaume Smet wrote: > On Wed, Jan 31, 2018 at 4:42 PM, Steve Ebersole > wrote: > >> The next time-box is in fact 2 weeks... :) >> >> But yes, OGM makes me a little nervous as as far as I know we have no >> idea about that integration yet >> > > We discussed it on Tuesday at our meeting. > > I think we can commit to getting your feedback on OGM in the next 2 weeks. > > Personally, I would like to have an OGM release supporting ORM 5.3 not > long ago after the ORM 5.3 release, even if we don't have any new features. > > -- > Guillaume > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3.0 release tomorrow
On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole wrote: > Yes, I agree. As it is, it is very likely that in 2 weeks we will have > ORM 5.3.0.CR1. So even if you did do a OGM release at that time we are > going to be limited in what exactly we can change if we find changes are > needed. > > Interestingly this goes back to earlier discussions about "release > early/often" for the purpose of identifying regressions. Granted there > y'all were talking about 5.2, but the same happens here from the ORM > perspective in 5.3. We need to not be dragging version non-stable releases > out as we continue to wait for +1's from all integrators (Search, OGM, > Spring, etc). > Yes, for a lot of reasons (good and bad) we were really bad with the ORM 5.2 support in OGM. We are very aware of that and the idea is to not do that again :). We (probably Davide) will let you know about our progress soon. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Should EntityManager#refresh retain an existing lock?
HHH-12257 involves refreshing an entity that is already has a pessimistic lock. In the test case attached to the jira, EntityManager#refresh(Object entity) is used to refresh the entity, instead of a method that specifies a particular LockModetype (e.g., #refresh(Object entity, LockModeType lockMode)). The lock on the refreshed entity is dropped. A workaround is to determine the current lock mode using Session#getCurrentLockMode, which returns a org.hibernate.LockMode object, which can be converted to a LockModeType that can be used to call EntityManager#refresh(Object entity, LockModeType lockMode). Unfortunately, the code that converts org.hibernate.LockMode to LockModeType is "internal" (org.hibernate.internal.util.LockModeConverter). I'm on the fence about how this should work. The API for EntityManager#refresh(Object entity) does not say that an existing lock mode on the entity should be retained. On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section seems to indicate that locks on an entity apply to the transaction, and does say that a lock on an entity should be dropped when refreshed without an specified LockModeType. Does anyone have any guidance on how this should work? Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Should EntityManager#refresh retain an existing lock?
Hi Gail, personally I wouldn't expect the pessimistic lock to be dropped. In case of optimistic locking, I would expect the version to be updated to the latest read - the one triggered by the refresh. I just read section 3.4 as you suggested but I couldn't find were it suggests that "a lock on an entity should be dropped when refreshed" ; what makes you think it indicates that? On the other hand, section 3.4.3 is quite explicit about no other changes being allowed by other transactions until the end of the transaction, which I guess makes sense. Would it even be possible to "unlock" a row on which we have a pessimistic lock without committing the transaction? I don't think that's possible, so that should clarify what needs to be done. Thanks, Sanne On 31 January 2018 at 20:51, Gail Badner wrote: > HHH-12257 involves refreshing an entity that is already has a pessimistic > lock. In the test case attached to the jira, EntityManager#refresh(Object > entity) is used to refresh the entity, instead of a method that specifies a > particular LockModetype (e.g., #refresh(Object entity, LockModeType > lockMode)). The lock on the refreshed entity is dropped. > > A workaround is to determine the current lock mode using > Session#getCurrentLockMode, which returns a org.hibernate.LockMode object, > which can be converted to a LockModeType that can be used to call > EntityManager#refresh(Object entity, LockModeType lockMode). > > Unfortunately, the code that converts org.hibernate.LockMode to > LockModeType is "internal" (org.hibernate.internal.util.LockModeConverter). > > I'm on the fence about how this should work. > > The API for EntityManager#refresh(Object entity) does not say that an > existing lock mode on the entity should be retained. > > On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section > seems to indicate that locks on an entity apply to the transaction, and > does say that a lock on an entity should be dropped when refreshed without > an specified LockModeType. > > Does anyone have any guidance on how this should work? > > Thanks, > Gail > ___ > 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] Should EntityManager#refresh retain an existing lock?
See below... On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero wrote: > Hi Gail, > > personally I wouldn't expect the pessimistic lock to be dropped. > In case of optimistic locking, I would expect the version to be > updated to the latest read - the one triggered by the refresh. > Yes, the version is updated, if necessary, on a refresh. > > I just read section 3.4 as you suggested but I couldn't find were it > suggests that "a lock on an entity should be dropped when refreshed" ; > what makes you think it indicates that? > Ah, that was a typo on my part, it should have said : > On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section > seems to indicate that locks on an entity apply to the transaction, and > *doesn't *say that a lock on an entity should be dropped when refreshed without > a specified LockModeType. I updated the thread below to make the correction (including a correction to a grammatical error.) > On the other hand, section 3.4.3 is quite explicit about no other > changes being allowed by other transactions until the end of the > transaction, which I guess makes sense. > > Would it even be possible to "unlock" a row on which we have a > pessimistic lock without committing the transaction? I don't think > that's possible, so that should clarify what needs to be done. > > It is possible to call EntityManager#lock(Object entity, LockModeType lockMode) with a lower-level lock, but that request will be ignored. Hibernate will only upgrade a lock. I think that clarifies retaining the same lock-level for the entity when calling EntityManager#refresh(Object entity). If no one has any comments that disagree with this in the next couple of days, I'll go with that. Thanks! Gail Thanks, > Sanne > > > > On 31 January 2018 at 20:51, Gail Badner wrote: > > HHH-12257 involves refreshing an entity that is already has a pessimistic > > lock. In the test case attached to the jira, EntityManager#refresh(Object > > entity) is used to refresh the entity, instead of a method that > specifies a > > particular LockModetype (e.g., #refresh(Object entity, LockModeType > > lockMode)). The lock on the refreshed entity is dropped. > > > > A workaround is to determine the current lock mode using > > Session#getCurrentLockMode, which returns a org.hibernate.LockMode > object, > > which can be converted to a LockModeType that can be used to call > > EntityManager#refresh(Object entity, LockModeType lockMode). > > > > Unfortunately, the code that converts org.hibernate.LockMode to > > LockModeType is "internal" (org.hibernate.internal.util. > LockModeConverter). > > > > I'm on the fence about how this should work. > > > > The API for EntityManager#refresh(Object entity) does not say that an > > existing lock mode on the entity should be retained. > > > The following contains a correction from the original: > > On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section > > seems to indicate that locks on an entity apply to the transaction, and > > *doesn't* say that a lock on an entity should be dropped when refreshed > without > > a specified LockModeType. > > > > Does anyone have any guidance on how this should work? > > > > Thanks, > > Gail > > ___ > > 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] Should EntityManager#refresh retain an existing lock?
On 31 January 2018 at 21:48, Gail Badner wrote: > See below... > > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero > wrote: >> >> Hi Gail, >> >> personally I wouldn't expect the pessimistic lock to be dropped. >> In case of optimistic locking, I would expect the version to be >> updated to the latest read - the one triggered by the refresh. > > > Yes, the version is updated, if necessary, on a refresh. > >> >> >> I just read section 3.4 as you suggested but I couldn't find were it >> suggests that "a lock on an entity should be dropped when refreshed" ; >> what makes you think it indicates that? > > > Ah, that was a typo on my part, it should have said : > >> On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section >> seems to indicate that locks on an entity apply to the transaction, and >> doesn't say that a lock on an entity should be dropped when refreshed >> without >> a specified LockModeType. > > I updated the thread below to make the correction (including a correction to > a grammatical error.) > >> >> On the other hand, section 3.4.3 is quite explicit about no other >> changes being allowed by other transactions until the end of the >> transaction, which I guess makes sense. >> >> Would it even be possible to "unlock" a row on which we have a >> pessimistic lock without committing the transaction? I don't think >> that's possible, so that should clarify what needs to be done. >> > > It is possible to call EntityManager#lock(Object entity, LockModeType > lockMode) with a lower-level lock, but that request will be ignored. > Hibernate will only upgrade a lock. Yes I understand what Hibernate does. I meant I don't think it would be possible to have it do otherwise, as I'm not aware of SQL instructions or JDBC methods to unlock a database entry w/o committing the transaction. I might be wrong: haven't used JDBC in years, hence I phrased it as a question.. but if I'm right then clearly we can't "undo" the pessimistic lock. > > I think that clarifies retaining the same lock-level for the entity when > calling EntityManager#refresh(Object entity). +1 Thanks, Sanne > > If no one has any comments that disagree with this in the next couple of > days, I'll go with that. > > Thanks! > Gail > >> Thanks, >> Sanne >> >> >> >> On 31 January 2018 at 20:51, Gail Badner wrote: >> > HHH-12257 involves refreshing an entity that is already has a >> > pessimistic >> > lock. In the test case attached to the jira, >> > EntityManager#refresh(Object >> > entity) is used to refresh the entity, instead of a method that >> > specifies a >> > particular LockModetype (e.g., #refresh(Object entity, LockModeType >> > lockMode)). The lock on the refreshed entity is dropped. >> > >> > A workaround is to determine the current lock mode using >> > Session#getCurrentLockMode, which returns a org.hibernate.LockMode >> > object, >> > which can be converted to a LockModeType that can be used to call >> > EntityManager#refresh(Object entity, LockModeType lockMode). >> > >> > Unfortunately, the code that converts org.hibernate.LockMode to >> > LockModeType is "internal" >> > (org.hibernate.internal.util.LockModeConverter). >> > >> > I'm on the fence about how this should work. >> > >> > The API for EntityManager#refresh(Object entity) does not say that an >> > existing lock mode on the entity should be retained. >> > > > > The following contains a correction from the original: > >> >> > On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section >> > seems to indicate that locks on an entity apply to the transaction, and >> > doesn't say that a lock on an entity should be dropped when refreshed >> > without >> > a specified LockModeType. >> > >> > Does anyone have any guidance on how this should work? >> > >> > Thanks, >> > Gail >> > ___ >> > 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] Should EntityManager#refresh retain an existing lock?
Ah, I see. Using H2, the lock is still held after calling EntityManager#refresh(Object entity), in spite of Hibernate setting the lock mode to NONE for the entity in the PersistenceContext. On Wed, Jan 31, 2018 at 2:11 PM, Sanne Grinovero wrote: > On 31 January 2018 at 21:48, Gail Badner wrote: > > See below... > > > > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero > > wrote: > >> > >> Hi Gail, > >> > >> personally I wouldn't expect the pessimistic lock to be dropped. > >> In case of optimistic locking, I would expect the version to be > >> updated to the latest read - the one triggered by the refresh. > > > > > > Yes, the version is updated, if necessary, on a refresh. > > > >> > >> > >> I just read section 3.4 as you suggested but I couldn't find were it > >> suggests that "a lock on an entity should be dropped when refreshed" ; > >> what makes you think it indicates that? > > > > > > Ah, that was a typo on my part, it should have said : > > > >> On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency section > >> seems to indicate that locks on an entity apply to the transaction, and > >> doesn't say that a lock on an entity should be dropped when refreshed > >> without > >> a specified LockModeType. > > > > I updated the thread below to make the correction (including a > correction to > > a grammatical error.) > > > >> > >> On the other hand, section 3.4.3 is quite explicit about no other > >> changes being allowed by other transactions until the end of the > >> transaction, which I guess makes sense. > >> > >> Would it even be possible to "unlock" a row on which we have a > >> pessimistic lock without committing the transaction? I don't think > >> that's possible, so that should clarify what needs to be done. > >> > > > > It is possible to call EntityManager#lock(Object entity, LockModeType > > lockMode) with a lower-level lock, but that request will be ignored. > > Hibernate will only upgrade a lock. > > Yes I understand what Hibernate does. I meant I don't think it would > be possible to have it do otherwise, as I'm not aware of SQL > instructions or JDBC methods to unlock a database entry w/o committing > the transaction. > I might be wrong: haven't used JDBC in years, hence I phrased it as a > question.. but if I'm right then clearly we can't "undo" the > pessimistic lock. > > > > > I think that clarifies retaining the same lock-level for the entity when > > calling EntityManager#refresh(Object entity). > > +1 > > Thanks, > Sanne > > > > > If no one has any comments that disagree with this in the next couple of > > days, I'll go with that. > > > > Thanks! > > Gail > > > >> Thanks, > >> Sanne > >> > >> > >> > >> On 31 January 2018 at 20:51, Gail Badner wrote: > >> > HHH-12257 involves refreshing an entity that is already has a > >> > pessimistic > >> > lock. In the test case attached to the jira, > >> > EntityManager#refresh(Object > >> > entity) is used to refresh the entity, instead of a method that > >> > specifies a > >> > particular LockModetype (e.g., #refresh(Object entity, LockModeType > >> > lockMode)). The lock on the refreshed entity is dropped. > >> > > >> > A workaround is to determine the current lock mode using > >> > Session#getCurrentLockMode, which returns a org.hibernate.LockMode > >> > object, > >> > which can be converted to a LockModeType that can be used to call > >> > EntityManager#refresh(Object entity, LockModeType lockMode). > >> > > >> > Unfortunately, the code that converts org.hibernate.LockMode to > >> > LockModeType is "internal" > >> > (org.hibernate.internal.util.LockModeConverter). > >> > > >> > I'm on the fence about how this should work. > >> > > >> > The API for EntityManager#refresh(Object entity) does not say that an > >> > existing lock mode on the entity should be retained. > >> > > > > > > > The following contains a correction from the original: > > > >> > >> > On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency > section > >> > seems to indicate that locks on an entity apply to the transaction, > and > >> > doesn't say that a lock on an entity should be dropped when refreshed > >> > without > >> > a specified LockModeType. > >> > > >> > Does anyone have any guidance on how this should work? > >> > > >> > Thanks, > >> > Gail > >> > ___ > >> > 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] Should EntityManager#refresh retain an existing lock?
> > It is possible to call EntityManager#lock(Object entity, LockModeType > lockMode) with a lower-level lock, but that request will be ignored. > Hibernate will only upgrade a lock. > Sure, this is in keeping with most (all?) databases - a transaction can only acquire more restrictive locks. > I think that clarifies retaining the same lock-level for the entity when > calling EntityManager#refresh(Object entity). > > If no one has any comments that disagree with this in the next couple of > days, I'll go with that. > That's the correct handling. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Should EntityManager#refresh retain an existing lock?
It should not set NONE in the PC even. It should only overwrite if the new lock mode is "greater than" the current one. For sure we used to have these checks, but apparently no regression tests for it. On Wed, Jan 31, 2018 at 4:55 PM Gail Badner wrote: > Ah, I see. > > Using H2, the lock is still held after calling EntityManager#refresh(Object > entity), in spite of Hibernate setting the lock mode to NONE for the > entity in the PersistenceContext. > > On Wed, Jan 31, 2018 at 2:11 PM, Sanne Grinovero > wrote: > > > On 31 January 2018 at 21:48, Gail Badner wrote: > > > See below... > > > > > > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero > > > wrote: > > >> > > >> Hi Gail, > > >> > > >> personally I wouldn't expect the pessimistic lock to be dropped. > > >> In case of optimistic locking, I would expect the version to be > > >> updated to the latest read - the one triggered by the refresh. > > > > > > > > > Yes, the version is updated, if necessary, on a refresh. > > > > > >> > > >> > > >> I just read section 3.4 as you suggested but I couldn't find were it > > >> suggests that "a lock on an entity should be dropped when refreshed" ; > > >> what makes you think it indicates that? > > > > > > > > > Ah, that was a typo on my part, it should have said : > > > > > >> On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency > section > > >> seems to indicate that locks on an entity apply to the transaction, > and > > >> doesn't say that a lock on an entity should be dropped when refreshed > > >> without > > >> a specified LockModeType. > > > > > > I updated the thread below to make the correction (including a > > correction to > > > a grammatical error.) > > > > > >> > > >> On the other hand, section 3.4.3 is quite explicit about no other > > >> changes being allowed by other transactions until the end of the > > >> transaction, which I guess makes sense. > > >> > > >> Would it even be possible to "unlock" a row on which we have a > > >> pessimistic lock without committing the transaction? I don't think > > >> that's possible, so that should clarify what needs to be done. > > >> > > > > > > It is possible to call EntityManager#lock(Object entity, LockModeType > > > lockMode) with a lower-level lock, but that request will be ignored. > > > Hibernate will only upgrade a lock. > > > > Yes I understand what Hibernate does. I meant I don't think it would > > be possible to have it do otherwise, as I'm not aware of SQL > > instructions or JDBC methods to unlock a database entry w/o committing > > the transaction. > > I might be wrong: haven't used JDBC in years, hence I phrased it as a > > question.. but if I'm right then clearly we can't "undo" the > > pessimistic lock. > > > > > > > > I think that clarifies retaining the same lock-level for the entity > when > > > calling EntityManager#refresh(Object entity). > > > > +1 > > > > Thanks, > > Sanne > > > > > > > > If no one has any comments that disagree with this in the next couple > of > > > days, I'll go with that. > > > > > > Thanks! > > > Gail > > > > > >> Thanks, > > >> Sanne > > >> > > >> > > >> > > >> On 31 January 2018 at 20:51, Gail Badner wrote: > > >> > HHH-12257 involves refreshing an entity that is already has a > > >> > pessimistic > > >> > lock. In the test case attached to the jira, > > >> > EntityManager#refresh(Object > > >> > entity) is used to refresh the entity, instead of a method that > > >> > specifies a > > >> > particular LockModetype (e.g., #refresh(Object entity, LockModeType > > >> > lockMode)). The lock on the refreshed entity is dropped. > > >> > > > >> > A workaround is to determine the current lock mode using > > >> > Session#getCurrentLockMode, which returns a org.hibernate.LockMode > > >> > object, > > >> > which can be converted to a LockModeType that can be used to call > > >> > EntityManager#refresh(Object entity, LockModeType lockMode). > > >> > > > >> > Unfortunately, the code that converts org.hibernate.LockMode to > > >> > LockModeType is "internal" > > >> > (org.hibernate.internal.util.LockModeConverter). > > >> > > > >> > I'm on the fence about how this should work. > > >> > > > >> > The API for EntityManager#refresh(Object entity) does not say that > an > > >> > existing lock mode on the entity should be retained. > > >> > > > > > > > > > > The following contains a correction from the original: > > > > > >> > > >> > On the other hand, in JPA 2.1 spec, 3.4 Locking and Concurrency > > section > > >> > seems to indicate that locks on an entity apply to the transaction, > > and > > >> > doesn't say that a lock on an entity should be dropped when > refreshed > > >> > without > > >> > a specified LockModeType. > > >> > > > >> > Does anyone have any guidance on how this should work? > > >> > > > >> > Thanks, > > >> > Gail > > >> > ___ > > >> > hibernate-dev mailing list > > >> > hibernate-dev@lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/hiberna
Re: [hibernate-dev] Should EntityManager#refresh retain an existing lock?
OK, sounds good. Thanks, Gail On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole wrote: > It is possible to call EntityManager#lock(Object entity, LockModeType >> lockMode) with a lower-level lock, but that request will be ignored. >> Hibernate will only upgrade a lock. >> > > Sure, this is in keeping with most (all?) databases - a transaction can > only acquire more restrictive locks. > > > >> I think that clarifies retaining the same lock-level for the entity when >> calling EntityManager#refresh(Object entity). >> >> If no one has any comments that disagree with this in the next couple of >> days, I'll go with that. >> > > That's the correct handling. > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3.0 release tomorrow
I am waiting until I hear back from Joel from Sonatype regarding disabling the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release. On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet wrote: > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole > wrote: > >> Yes, I agree. As it is, it is very likely that in 2 weeks we will have >> ORM 5.3.0.CR1. So even if you did do a OGM release at that time we are >> going to be limited in what exactly we can change if we find changes are >> needed. >> >> Interestingly this goes back to earlier discussions about "release >> early/often" for the purpose of identifying regressions. Granted there >> y'all were talking about 5.2, but the same happens here from the ORM >> perspective in 5.3. We need to not be dragging version non-stable releases >> out as we continue to wait for +1's from all integrators (Search, OGM, >> Spring, etc). >> > > Yes, for a lot of reasons (good and bad) we were really bad with the ORM > 5.2 support in OGM. > > We are very aware of that and the idea is to not do that again :). > > We (probably Davide) will let you know about our progress soon. > > -- > Guillaume > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
