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

[Sanne Grinovero]

Actually those tests just failed, so that's not it.

On 21 November 2016 at 11:15, Sanne Grinovero <sanne at 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 <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