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

[Gail Badner]

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.

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