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

[Gail Badner]

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 at hibernate.org>
wrote:

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