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.v...@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 <gbad...@redhat.com> wrote: > >> OK, sounds good. >> >> Thanks, >> Gail >> >> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <st...@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@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
