Re: [hibernate-dev] Should EntityManager#refresh retain an existing lock?
On 31 January 2018 at 21:48, Gail Badner <gbadner(a)redhat.com> wrote:
See below...
On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev