Jim Newsham wrote:
Hi,
I got a curious error message and was wondering if there was an
explanation for the cause, or if this was due to a bug. This is the
first time I’ve seen it, so I’m not sure how often it occurs. Here is
relevant portion of the stack trace:
Caused by: java.sql.SQLException: Container 2,385 not found.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown
Source)
Here is some background on the app and what I was recently doing:
My application is data-intensive… there are very frequent
transactional inserts and queries from multiple threads. Insert
transactions are largish (several hundred records). I have found that
transactions occasionally time out, perhaps due to concurrent access
and locking, so I have retry logic to handle the failure. The retry
could perhaps use some refining, but currently: when an exception (of
any type) occurs, I log an error message and retry, up to two more
times, with no intervening delay; after that, I give up and log a
stack trace. I occasionally see a logged retry message, but I
typically don’t see failure and a logged stack trace.
Now, I am in the process of adding functionality to allow the user to
invoke a command to compact the database (derby calls this compress,
but compact seems more appropriate). The compact command calls
syscs_util.syscs_compress_table(schema_name, table_name, 1) for each
table in the database, one at a time. When I invoked this command, a
concurrently running insert transaction failed with the above stack
trace. As described above, I need to fail three times to get the stack
trace, so I can’t be certain what the previous two failures for that
transaction were. I did see logged retries for other insert
transactions, but no stack trace, indicating that those eventually
succeeded.
Regards,
Jim Newsham
Hi Jim -
I think you have encountered a bug. COMPRESS TABLE should acquire an
exclusive lock on the table and not allow any activity against the table
until the process is complete. The error you are getting could mean that
not everything was ready to go when your insert began.
In Derby a database file is referred to as a container - assuming that
space is freed by COMPRESS TABLE, empty database files will be removed.
The message: Container 2,385 not found. implies (to me, anyway) that a
reference to one of the files removed by COMPRESS TABLE was 'found' by
your INSERT but subsequent activity (a write to disk?) did NOT file the
file thus causing the failure. I am hoping that this is a transient,
in-memory problem and does not indicate database corruption but would
recommend you run CHECKTABLE to insure that everything cleaned up nicely
and not permanent problems exist.
Please report this to derby-dev where you can get advice from a Derby
developer. I suspect they will ask you to file a JIRA entry - could you
provide a test case for this problem?
