1

I have two entity managers (and this has to stay as it is). I am using in-memory database for unit tests. When I run the tests, I find the following issues.

As in this simple case:

  emFirst.createNativeQuery("select * from schema1.table").getResultList();

  emSecond.createNativeQuery("create table schema2.table (id int)").executeUpdate();

It gets stuck in a deadlock after upgrading HSQL from 2.3.2 to 2.3.4

In order to to make it work again i have to wrap each statement in transaction.

Do you know how can I make it work without using below?

    getTransaction().begin();
    emFirst.createNativeQuery("select * from schema1.table").getResultList();
    getTransaction().commit();

    getTransaction().begin();         
    emSecond.createNativeQuery("create table schema2.table (id int)").executeUpdate();
    getTransaction().commit();

I am using Hibernate 4.3.6

Here is a heap dump from deadlock:

> "main" #1 prio=5 os_prio=0 tid=0x00007f7be0015000 nid=0x3b29 waiting
> on condition [0x00007f7be8584000]    java.lang.Thread.State: WAITING
> (parking)     at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000000073635b3d0> (a org.hsqldb.lib.CountUpDownLatch$Sync)    at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at org.hsqldb.lib.CountUpDownLatch.await(Unknown Source)    at
> org.hsqldb.Session.executeCompiledStatement(Unknown Source)   at
> org.hsqldb.Session.execute(Unknown Source)
>   - locked <0x000000073635b298> (a org.hsqldb.Session)    at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source)    at
> org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown Source)
>   - locked <0x00000007363a92f8> (a org.hsqldb.jdbc.JDBCPreparedStatement)     at
> com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:147)
>   at
> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208)
>   at
> org.hibernate.engine.query.spi.NativeSQLQueryPlan.performExecuteUpdate(NativeSQLQueryPlan.java:211)
>   at
> org.hibernate.internal.SessionImpl.executeNativeUpdate(SessionImpl.java:1310)
>   at
> org.hibernate.internal.SQLQueryImpl.executeUpdate(SQLQueryImpl.java:389)
Adam Soliński
  • 444
  • 1
  • 8
  • 19
Maciej
  • 532
  • 2
  • 10
  • 19
  • 1
    Possibly this? https://stackoverflow.com/questions/14001558/maven-hangs-while-running-test-case-eclipselink-hsqldb – rogerdpack Jul 28 '20 at 19:07

2 Answers2

0

Use an HSQLDB Server instead of an in-process database.

fredt
  • 24,044
  • 3
  • 40
  • 61
  • The database is used in unit tests. Hence it is supposed to be in-memory db. I will edit the original post – Adam Soliński Jan 14 '17 at 10:07
  • You can start a server with an in-memory database. The server could be started from your app. In that case the CREATE statement will wait for the emFirst to commit. – fredt Jan 14 '17 at 11:13
  • I see your point. But why does it wait? what has changed there since HSQL 2.3.2? Why would now commit for a readonly SELECT be needed on hibernate session level? – Adam Soliński Jan 14 '17 at 11:18
  • 1
    What has changed is HSQLDB 2.3.4 now waits for all transactions (including SELECT) to commit before executing CREATE TABLE or any other DDL statement. This may improve in next version. – fredt Jan 14 '17 at 12:00
0

Probably switching to MVCC mode might work, see http://hsqldb.org/doc/2.0/guide/dbproperties-chapt.html#dpc_db_operations. Appending ;hsqldb.tx=mvcc to the connection url didn't help in my case. I use an in-memory database which reads a file based predefined db from the classpath (jdbc:hsqldb:res:). Explicitly calling SET DATABASE TRANSACTION CONTROL MVCC in the test setup did the trick.

richardb
  • 141
  • 7