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

[Gail Badner]

Steve,

I ran into a snag when fixing this.

Please take a look at my pull request:
https://github.com/hibernate/hibernate-orm/pull/2167

Thanks,
Gail

On Thu, Feb 1, 2018 at 5:39 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Gail,
>
> Steve is right. Database locks cannot be released unless you end the
> transaction and that's how it works on any RDBMS, either in 2PL Mode or
> MVCC.
>
> As for optimistic locks:
>
> 1. LockModeType.OPTIMISTIC
>
> The check is done at the end of the end of the transaction. Refresh will
> only update the version, but the check should still be done so we should
> not probably switch to LockModeTypeNONE.
>
> 2. OPTIMISTIC_FORCE_INCREMENT,
>
> This one triggers a version increment in a different entity, so it should
> not be affected by the refresh of our entity.
>
> Vlad
>
> On Thu, Feb 1, 2018 at 1:12 AM, Gail Badner <gbadner at redhat.com> wrote:
>
>> OK, sounds good.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > 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.
>> >>
>> >
>> > Sure, this is in keeping with most (all?) databases - a transaction can
>> > only acquire more restrictive locks.
>> >
>> >
>> >
>> >> 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.
>> >>
>> >
>> > That's the correct handling.
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>