On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)hibernate.org>
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
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
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.
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
> 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
> 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.
> 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
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