[hibernate-dev] Change in DB lock acquisition in ORM?

[Vlad Mihalcea]

The only thing related to transaction handling was the way connection are
released. Now, we are using AFTER_TRANSACTION instead of ON_CLOSE for
resource local ones.
But that should not impact your test, I guess.

Vlad

On Mon, Nov 21, 2016 at 4:44 PM, Steve Ebersole <steve at hibernate.org> wrote:

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