Startup of hsqldb fails due to table locks

Help
2012-10-17
2014-01-19
  • Christian3242

    Christian3242 - 2012-10-17

    We have encountered the following issue (both with hsqldb 2.2.8 and 2.2.9):

    After an unclean shutdown of hsqldb (killing the process), the database log file is not consolidated (as expected). We frequently use table locks in our system from multiple threads and multiple nodes on one hsqldb instance. Within the database log file those statements appear as:

    LOCK TABLE lock_table WRITE
    

    We could not start hsqldb, if there were multiple consecutive lock statements within the log file.

    LOCK TABLE lock_table WRITE
    
    LOCK TABLE lock_table WRITE
    

    The initalization hangs and no error ouput is produced. In the sql log file (file ending with ".sql.log") the last two statements are two consecutive lock tabel statements.

    Jstack reports no deadlocks but:

    Thread 30525: (state = BLOCKED)
     - sun.misc.Unsafe.park(boolean, long) @bci=0 (Interpreted frame)
     - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=156 (Interpreted frame)
     - java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt() @bci=1, line=811 (Interpreted frame)
     - java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(int) @bci=55, line=969 (Interpreted frame)
     - java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(int) @bci=24, line=1281 (Interpreted frame)
     - java.util.concurrent.CountDownLatch.await() @bci=5, line=207 (Interpreted frame)
     - org.hsqldb.lib.CountUpDownLatch.await() @bci=12 (Interpreted frame)
     - org.hsqldb.Session.executeCompiledStatement(org.hsqldb.Statement, java.lang.Object[]) @bci=260 (Interpreted frame)
     - org.hsqldb.persist.ScriptRunner.runScript(org.hsqldb.Database, org.hsqldb.scriptio.ScriptReaderBase) @bci=294 (Interpreted frame)
     - org.hsqldb.persist.ScriptRunner.runScript(org.hsqldb.Database, java.lang.String) @bci=68 (Interpreted frame)
     - org.hsqldb.persist.Log.processLog() @bci=24 (Interpreted frame)
     - org.hsqldb.persist.Log.open() @bci=134 (Interpreted frame)
     - org.hsqldb.persist.Logger.openPersistence() @bci=1017 (Interpreted frame)
     - org.hsqldb.Database.reopen() @bci=152 (Interpreted frame)
     - org.hsqldb.Database.open() @bci=9 (Interpreted frame)
     - org.hsqldb.DatabaseManager.getDatabase(java.lang.String, java.lang.String, org.hsqldb.persist.HsqlProperties) @bci=66 (Interpreted frame)
     - org.hsqldb.DatabaseManager.getDatabase(java.lang.String, java.lang.String, org.hsqldb.server.Server, org.hsqldb.persist.HsqlProperties) @bci=3 (Interpreted frame)
     - org.hsqldb.server.Server.openDatabases() @bci=106 (Interpreted frame)
     - org.hsqldb.server.Server.run() @bci=114 (Interpreted frame)
     - org.hsqldb.server.Server.access$000(org.hsqldb.server.Server) @bci=1 (Interpreted frame)
     - org.hsqldb.server.Server$ServerThread.run() @bci=4 (Interpreted frame)
    

    After removing these consecutive statements, so that each is followed by a commit in the database log file, hsqldb could be started properly.

    Our workaround is to delete all lock table statements whenever a .log file is present before hsqldb is actually started.

    Does this represent a bug? Are there any options that can be used for startup that will result in a different way the log file is interpreted?

    Many Thanks.

     
  • Fred Toussi

    Fred Toussi - 2012-10-17

    Thanks for reporting.

    The LOCK TABLE statements shouldn't really be logged, as they are not necessary for recovery. Will be fixed in the next snapshot jar, which you can use in production.

     
  • Fred Toussi

    Fred Toussi - 2012-10-24

    Issue has been fixed in the latest snapshot jar.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks