[hibernate-dev] Change in DB lock acquisition in ORM?
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 JBoss Performance Team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Change in DB lock acquisition in ORM?
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=1 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 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 > 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
Re: [hibernate-dev] Change in DB lock acquisition in ORM?
Actually those tests just failed, so that's not it. On 21 November 2016 at 11:15, 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=1 > > 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 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 >> 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
Re: [hibernate-dev] Change in DB lock acquisition in ORM?
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=1 > > 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 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 >> JBoss Performance Team >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa JBoss Performance Team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Change in DB lock acquisition in ORM?
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 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=1 > > > > 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 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 > >> JBoss Performance Team > >> > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Radim Vansa > 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
Re: [hibernate-dev] Change in DB lock acquisition in ORM?
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 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 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=1 > > > > > > 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 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 > > >> JBoss Performance Team > > >> > > >> ___ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > > Radim Vansa > > 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
