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(a)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-infinisp...
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev