#1756 DatabaseMetaData.getTables() fails with "General error" when another session concurrently creates or drops a table
Since 2.7.4, SchemaManager.databaseTableIterator() and SchemaManager.databaseObjectIterator(int) return live iterators over the internal schema maps instead of the array snapshot that 2.7.2 and earlier took while holding readLock. The read lock is released when the method returns, so the caller — DatabaseInformationMain, which builds SYSTEM_TABLES and the other system tables — iterates those maps completely unsynchronized.
If any other session executes CREATE TABLE or DROP TABLE while the system table is being generated, the underlying BaseHashMap iterator observes an inconsistent state and throws ArrayIndexOutOfBoundsException / NoSuchElementException / NullPointerException. These are caught by Result.newErrorResult(Throwable, String), which maps anything that is not an HsqlException, OutOfMemoryError or IOException to error code 458, so the client only ever sees:
java.sql.SQLException: General error (errorCode = -458, SQLState = S1000)
Occasionally the same table is visited twice and generation fails with a different symptom:
errorCode=-104 sqlState=23505
integrity constraint violation: unique constraint or index violation ; SYSTEM_TABLES table: SYSTEM_TABLES
There is no application-level workaround other than serializing every DDL statement against every metadata call across the whole JVM, which is not possible when several independent components share one database.
Affected versions
| Version | Result |
|---|---|
| 2.4.1 | not affected |
| 2.5.2 | not affected |
| 2.7.2 | not affected |
| 2.7.4 | affected |
SVN trunk (base/trunk/src/org/hsqldb/SchemaManager.java, ~lines 1820–1850) |
still affected |
Tested with JDK 21.0.6 on Windows 11, 8 logical CPUs, using the released jars.
Please refer to the attached zip file for details.
Thank you for the detailed report. Fixed and committed to SVN.