foss1024

I think the following patch is closer: . RowLockInterruptTest and RowLockInterruptTestWithThread both pass . HypersonicCheckpointTest3 and HypersonicCheckpointTestWithSeparateThread both fail in MVCC mode with "Original connection is broken: transaction rollback: serialization failure" at insertFoo(connection, "4");. So some internal state isn't being reset, and I don't know this code well enough to know where and what to look for. They both pass in Locks mode where as r6590 doesn't throw the expected...

I'm not sure I follow. I changed this line in the test so I could find the thread a little easier... final Thread otherThread = new Thread("otherThread") { If I create a thread dump, I see it's stuck on CountUpDownLatch.await() which does respond to an InterruptedException, but it is stuck in another while loop. "otherThread" #20 prio=5 os_prio=0 tid=0x00007f66003f8000 nid=0x3ac9de waiting on condition [0x00007f6593b9e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method)...

We see the same behavior if I create a separate thread for connection2. See RowLockInterruptTestWithThread.

Here's basically the same test, except this time I used row locks instead of using backup and what I assume were table locks. In Locks mode, it fails to throw an exception (java.sql.SQLTransactionRollbackException) when the second connection is interrupted. JUnit doesn't report failures until both tests complete, and since MVCC isn't currently completing, you can only see this assertion failure by commenting out testMvcc. 1) testLocks(RowLockInterruptTest) junit.framework.AssertionFailedError: Expected...

The backup files don't appear to be created until after the thread is interrupted. backupLocation = /tmp/backup2619247496809045225/hslqdb-backup.tar.gz Issuing backup. Interrupting: Thread[main,5,main] 1 / 2 test.properties... 2 / 2 test.script... Issuing backup completed.

HypersonicCheckpointTest2 does pass, but it is not rolling back the first backup as expected after the backup is interrupted. I modified the test and created HypersonicCheckpointTest3 which verifies that the first backup is rolled back to check for this. Side note: if you comment out these 2 lines, you can also see the backups that are generated. backupLocation.delete(); tempDirectory.delete(); The first backup includes INSERT INTO FOO VALUES('2') which is unexpected as that transaction isn't complete...

HypersonicCheckpointTest2 does pass, but it is not rolling back the first backup as expected after the backup is interrupted. I modified the test and created HypersonicCheckpointTest3 which verifies that the first backup is rolled back to check for this. Side note: if you comment out these 2 lines, you can also see the backups that are generated. backupLocation.delete(); tempDirectory.delete(); The first backup includes INSERT INTO FOO VALUES('2') which is unexpected as that transaction isn't complete...

It looks like you are reusing the original statement from the original connection to do the last backup. Also, if you comment out the entire try/catch around insertFoo(connection, "4"), the next statement hangs whether it is the same statement or a new statement from the same connection.