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.
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?
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.
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.
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
does say that a lock on an entity should be dropped when refreshed without
an 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