db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Newsham" <jnews...@referentia.com>
Subject Container 2,385 not found
Date Tue, 20 Feb 2007 22:20:04 GMT
 

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


Mime
View raw message