This is with derby 10.2.2.0.
_____ From: Jim Newsham [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 20, 2007 12:20 PM To: 'Derby Discussion' Subject: Container 2,385 not found 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(Unknow n 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
