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

[Sanne Grinovero]

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