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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

See below... On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; 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 <gbadner(a)redhat.com&gt; 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <sanne(a)hibernate.org&gt; wrote: > On 31 January 2018 at 21:48, Gail Badner <gbadner(a)redhat.com&gt; wrote: > > See below... > > > > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; > > 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 <gbadner(a)redhat.com&gt; 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(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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.

Hi Gail, Steve is right. Database locks cannot be released unless you end the transaction and that's how it works on any RDBMS, either in 2PL Mode or MVCC. As for optimistic locks: 1. LockModeType.OPTIMISTIC The check is done at the end of the end of the transaction. Refresh will only update the version, but the check should still be done so we should not probably switch to LockModeTypeNONE. 2. OPTIMISTIC_FORCE_INCREMENT, This one triggers a version increment in a different entity, so it should not be affected by the refresh of our entity. Vlad On Thu, Feb 1, 2018 at 1:12 AM, Gail Badner <gbadner(a)redhat.com&gt; wrote: > OK, sounds good. > > Thanks, > Gail > > On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve(a)hibernate.org&gt; > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >