Re: [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 
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  wrote:
>
>> OK, sounds good.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole 
>> 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Vlad Mihalcea]

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

> OK, sounds good.
>
> Thanks,
> Gail
>
> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole 
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Gail Badner]

OK, sounds good.

Thanks,
Gail

On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole  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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Steve Ebersole]

It should not set NONE in the PC even.  It should only overwrite if the new
lock mode is "greater than" the current one.  For sure we used to have
these checks, but apparently no regression tests for it.


On Wed, Jan 31, 2018 at 4:55 PM Gail Badner  wrote:

> Ah, I see.
>
> Using H2, the lock is still held after calling EntityManager#refresh(Object
>  entity), in spite of Hibernate setting the lock mode to NONE for the
> entity in the PersistenceContext.
>
> On Wed, Jan 31, 2018 at 2:11 PM, Sanne Grinovero 
> wrote:
>
> > On 31 January 2018 at 21:48, Gail Badner  wrote:
> > > See below...
> > >
> > > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero 
> > > 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  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 

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

[Steve Ebersole]

>
> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Gail Badner]

Ah, I see.

Using H2, the lock is still held after calling EntityManager#refresh(Object
 entity), in spite of Hibernate setting the lock mode to NONE for the
entity in the PersistenceContext.

On Wed, Jan 31, 2018 at 2:11 PM, Sanne Grinovero 
wrote:

> On 31 January 2018 at 21:48, Gail Badner  wrote:
> > See below...
> >
> > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero 
> > 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  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@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Sanne Grinovero]

On 31 January 2018 at 21:48, Gail Badner  wrote:
> See below...
>
> On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero 
> 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  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@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Gail Badner]

See below...

On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero 
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.

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.

Thanks!
Gail

Thanks,
> Sanne
>
>
>
> On 31 January 2018 at 20:51, Gail Badner  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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Sanne Grinovero]

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  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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Gail Badner]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev