See below... On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sa...@hibernate.org> 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 <gbad...@redhat.com> 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
