Actually those tests just failed, so that's not it.
On 21 November 2016 at 11:15, Sanne Grinovero <sa...@hibernate.org> 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
