9:51 p.m.
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
10:20 p.m.
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
10:48 p.m.
See below...
On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)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.
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 <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.
>
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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
11:11 p.m.
On 31 January 2018 at 21:48, Gail Badner <gbadner(a)redhat.com> wrote:
See below...
On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)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(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.
> >
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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:35 p.m.
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 <sanne(a)hibernate.org>
wrote:
On 31 January 2018 at 21:48, Gail Badner <gbadner(a)redhat.com>
wrote:
> See below...
>
> On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)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(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.
>> >
>
>
> 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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
11:38 p.m.
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.
12:02 a.m.
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 <gbadner(a)redhat.com> 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 <sanne(a)hibernate.org>
wrote:
> On 31 January 2018 at 21:48, Gail Badner <gbadner(a)redhat.com> wrote:
> > See below...
> >
> > On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero <sanne(a)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(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.
> >> >
> >
> >
> > 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(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:12 a.m.
OK, sounds good.
Thanks,
Gail
On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve(a)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.
2:39 p.m.
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(a)redhat.com> wrote:
OK, sounds good.
Thanks,
Gail
On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:19 a.m.
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(a)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(a)redhat.com> wrote:
> OK, sounds good.
>
> Thanks,
> Gail
>
> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
2249
days inactive
2277
days old
9 comments
4 participants
participants (4)
-
Gail Badner -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea