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

[Steve Ebersole]

It should not set NONE in the PC even.  It should only overwrite if the new
lock mode is "greater than" the current one.  For sure we used to have
these checks, but apparently no regression tests for it.


On Wed, Jan 31, 2018 at 4:55 PM Gail Badner <gbadner at redhat.com> wrote:

> 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
> > >
> > >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>