Steve,
I ran into a snag when fixing this.
Please take a look at my pull request:
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
>