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