[hibernate-dev] Change in DB lock acquisition in ORM?
Steve Ebersole
steve at hibernate.org
Mon Nov 21 09:44:54 EST 2016
The change in exception type is new to 5.2 (merging HEM into core). IIRC
you did not "see failures in hibernate-infinispan tests" because we had
those disabled due to their ongoing intermittent failures.
On Mon, Nov 21, 2016 at 5:46 AM Radim Vansa <rvansa at redhat.com> wrote:
> Aha, that explains why the test take much longer. I was just about to
> look this up. I'll see if I can shorten this for tests where we expect
> such situations.
>
> Nevertheless, the test seems to be failing because it used to throw
> org.hibernate. PessimisticLockException and now it is throwing
> javax.persistence.PessimisticLockException (the hibernate exception is
> provided as cause).
>
> Radim
>
> On 11/21/2016 12:15 PM, Sanne Grinovero wrote:
> > Hi Radim,
> > I was wondering the same; I am not sure yet if it's related, but
> > noticed that the JDBC connection URL changed from
> >
> > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1
> >
> > to
> >
> > jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;LOCK_TIMEOUT=10000
> >
> > I'm running the testsuite now reverting that change locally, but I
> > can't say yet as the tests take ages to run...
> >
> > If anyone knows of other locking related changes please let us know :)
> >
> > Thanks,
> > Sanne
> >
> >
> > On 21 November 2016 at 10:04, Radim Vansa <rvansa at redhat.com> wrote:
> >> Hi,
> >>
> >> I am investigating the failures in hibernate-infinispan testsuite and
> >> I've found that [1] is failing as this uses two threads that both do
> >>
> >> 1. load entity
> >> 2. delete entity
> >> 3. flush session
> >> 4. commit tx
> >>
> >> on the same entity. There is a synchronization blocking the commit until
> >> both threads flush, and since the first thread holds a H2 DB lock on the
> >> entity, the other thread is blocked doing the flush on this lock.
> >>
> >> It makes sense to me, but I wonder why did the test work in the past.
> >> Was there a change in some locking defaults (optimistic/pessimistic) or
> >> was there anything delegating the lock acquisition to the commit instead
> >> of flush? The test works on 5.0.10.
> >>
> >> Radim
> >>
> >> [1]
> >>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/functional/TombstoneTest.java#L37
> >>
> >>
> >> --
> >> Radim Vansa <rvansa at redhat.com>
> >> JBoss Performance Team
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list