Re: [hibernate-dev] Should EntityManager#refresh retain an existing lock?

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 > >