HSQLDB sem desligamento elegante

Não uso o HSQLDB, mas achei algo que talvez possa te ajudar:

http://hsqldb.org/doc/guide/apc.html

Appendix C. Hsqldb Database Files and Recovery

Database is aborted

This may happen by sudden power off, Ctrl+C in Windows, but may be simulated using the command SHUTDOWN IMMEDIATELY.

Aborted Database state

The test.properties still containes 'modified=yes'.
  The test.script contains a snapshot of the database at the last checkpoint and is OK.
  The test.data file [b]may be corrupt because the cache in memory was not written out completely[/b].
  The test.backup file contains a snapshot of test.data that corresponds to test.script.
  The test.log file contain all information to re-do all changes since the snanapshot. As a result of abnormal termination, this file may be partially corrupt. </blockquote>

Repair

The current test.data file is corrupt, but with the old test.data (from the test.backup file and test.script) and the current test.log, the database is made up-to-date. The database engine takes these steps:

Procedure C.3. Database Repair

1. Restore the old test.data file from the backup (uncompress the test.backup and overwrite test.data).
2. Execute all commands in the test.script file.
3. Execute all commands in the test.log file. If due to corruption, an exception is thrown, the rest of the lines of command in the test.log file are ignored.
4. Close the database correctly (including a backup).

Acho que não. Mesmo se tentar recuperar os dados ainda vai ter corrompidos depois do desligamento forçado. Achava que o log não era corrompido neste caso :?

RafaelViana:

Não uso o HSQLDB, mas achei algo que talvez possa te ajudar:

http://hsqldb.org/doc/guide/apc.html

O guide foi o primeiro lugar que eu olhei. Mas, infelizmente, isso só constata que ele corrompe mesmo. =/
Eu imaginei que não teria nenhum jeito de contornar o problema. Parece ser uma falha da arquitetura dele.

E o bichinho corrompe fácil, fácil. O jeito é apelar para um “workaround” (para não dizer xunxo mesmo).

Tanto que não é recomendado para produção… mas a gente usa
Alguma das configurações dele (in-memory e tal) deve ser melhor neste caso… mas nenhuma parece resolver o problema. Tivemos problema com ele também neste caso… mas como é servidor que fica ligado sempre e as informações podem ser facilmente recuperadas isso foi deixado de lado.

Aqui usamos o HSQLDB em uma aplicação embarcada que não pode falhar.

A solução que encontramos foi usar um workaround:

Temos um job que fica rodando a cada tanto tempo chamando o comando CHECKPOINT, e às vezes faz o defrag do log também.

Aqui não tivemos perda de performance, pois o BD é usado somente com a aplicação local.

http://hsqldb.org/doc/guide/ch09.html#checkpoint-section