HSLQDB + JPA2 (with Hibernate) - The app gets stuck when trying a TRUNCATE SCHEMA

My app implements Deltaspike v1.6 and uses Hibernate v4.3.8. It also uses C3P0 v0.9.5.4
My regression tests use TestNG v7 and HSQLDB v2.4

Situation:
I'm coding some regression tests using TestNG for tests themselves, and HSQLDB as an on-mem db (on-file actually). I also use testng's dataproviders

The issue:
After each scenario in the dataprovider database must be cleaned. Therefore, I attempt to clean the database in the @AfterMethod method in this way:

public void resetDb() {
  em.getTransaction().begin();
   em.createNativeQuery("TRUNCATE SCHEMA PUBLIC RESTART IDENTITY AND COMMIT NO CHECK").executeUpdate();
  em.getTransaction().commit();    
}

The running gets stuck at em.createNativeQuery... line. I debugged this step by step and have enabled all kind of loging, It just stops there.
This is the last thing hibnernate logs in the console:

Hibernate: 
    TRUNCATE SCHEMA PUBLIC RESTART IDENTITY 
    AND COMMIT NO CHECK

In my log file I keep getting these logs, which I think are normal?

2020-10-22 14:15:43 TRACE ThreadPoolAsynchronousRunner:196 - com.mchange.v2.async.ThreadPoolAsynchronousRunner@7dbbf730: Adding task to queue -- com.mchange.v2.resourcepool.BasicResourcePool$1RefurbishCheckinResourceTask@284e5784
2020-10-22 14:15:43 TRACE BasicResourcePool:196 - trace com.mchange.v2.resourcepool.BasicResourcePool@31f9f9b3 [managed: 50, unused: 47, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@12f66dd1)
2020-10-22 14:15:49 TRACE ThreadPoolAsynchronousRunner:196 - com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@1677180d -- Running DeadlockDetector[Exiting. No pending tasks.]
2020-10-22 14:15:59 TRACE ThreadPoolAsynchronousRunner:196 - com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@1677180d -- Running DeadlockDetector[Exiting. No pending tasks.]
...
2020-10-22 14:17:09 TRACE ThreadPoolAsynchronousRunner:196 - com.mchange.v2.async.ThreadPoolAsynchronousRunner@7dbbf730: Adding task to queue -- com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@246b9ea4
2020-10-22 14:17:09 TRACE ThreadPoolAsynchronousRunner:196 - com.mchange.v2.async.ThreadPoolAsynchronousRunner@7dbbf730: Adding task to queue -- com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@7f791d48
2020-10-22 14:17:09 TRACE ThreadPoolAsynchronousRunner:196 - com.mchange.v2.async.ThreadPoolAsynchronousRunner@7dbbf730: Adding task to queue -- com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask@162d1ed8
2020-10-22 14:17:09 TRACE BasicResourcePool:196 - trace com.mchange.v2.resourcepool.BasicResourcePool@31f9f9b3 [managed: 50, unused: 48, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@12f66dd1)
2020-10-22 14:17:09 DEBUG C3P0PooledConnectionPool:204 - Testing PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@79c8cd43] on IDLE CHECK.
2020-10-22 14:17:09 DEBUG C3P0PooledConnectionPool:204 - Testing PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@6c2c47fe] on IDLE CHECK.
2020-10-22 14:17:09 DEBUG C3P0PooledConnectionPool:204 - Testing PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@723253a6] on IDLE CHECK.
2020-10-22 14:17:09 DEBUG C3P0PooledConnectionPool:204 - Test of PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@723253a6] on IDLE CHECK has SUCCEEDED.
2020-10-22 14:17:09 DEBUG C3P0PooledConnectionPool:204 - Test of PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@6c2c47fe] on IDLE CHECK has SUCCEEDED.
2020-10-22 14:17:09 DEBUG C3P0PooledConnectionPool:204 - Test of PooledConnection [com.mchange.v2.c3p0.impl.NewPooledConnection@79c8cd43] on IDLE CHECK has SUCCEEDED.

On a SIDE NOTE, I've tried truncating a table like this:

TRUNCATE TABLE [table_name] RESTART IDENTITY

It works, but when I try this one:

TRUNCATE TABLE "+table+" RESTART IDENTITY AND COMMIT NO CHECK

It DOESN't WORK, it gets stuck too. I think the "AND COMMIT" part is causing some kind of deadlock

The TRUNCATE .. AND COMMIT statement needs to obtain an exclusive lock on the database. It seems another session is active and has started a transaction that is not committed.