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 <st...@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 <rva...@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 <rva...@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 <rva...@redhat.com> > > >> JBoss Performance Team > > >> > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > > Radim Vansa <rva...@redhat.com> > > JBoss Performance Team > > > > _______________________________________________ > > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
