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

[Sanne Grinovero]

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