Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (herse.apache.org: 32.97.110.150 is neither permitted
 nor denied by domain of Stan.Bradbury@gmail.com)
Message-ID: <45DBA554.10809@gmail.com>
Date: Tue, 20 Feb 2007 17:50:12 -0800
From: Stanley Bradbury <Stan.Bradbury@gmail.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Container 2,385 not found
References: <000a01c7553d$4895c790$8700a8c0@referentia.com>
In-Reply-To: <000a01c7553d$4895c790$8700a8c0@referentia.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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?