Attached are a couple of test programs to reproduce the error with Derby 10.4.1.3 in embedded mode:

CompressDBTest1.java - tries to read a table while it is being compressed. The select statement errors out with the following error:
java.sql.SQLException: Container 2,192 not found.
Subsequent SELECTs with a brand new connection also fail with a little bit different error:
The conglomerate (2,192) requested does not exist.

CompressDBTest2.java - tries to insert data into a table while it is being compressed. The insert errors out eventually with the following error:
A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : TABLE, TEST, Tablelock
  Waiting XID : {236439, IX} , APP, insert into test values(?, ?, ?, ?, ?)
  Granted XID : {234342, X}
Lock : ROW, SYSCONGLOMERATES, (5,14)
  Waiting XID : {234342, X} , APP, alter table "APP"."TEST" compress sequential
  Granted XID : {234342, S} , {236439, S}
. The selected victim is XID : 236439.

What the test classes do:

Both classes first create a database named test under the current working directory if a directory named test does not already exist. Then a table named test is created and populated with 100,000 random records. Two threads are started then with the first one repeatedly compressing the test table and the second one repeatedly executing a DML statement. If the DML statement errors out, the compression thread will be stopped. Finally the database is shutdown. The standard output of the program goes to stdout.log and standard error goes to stderr.log in the current working directory.

In my tests, it did not take more than 10 to 20 seconds to see the error(s). Hope this helps. Please let me know if you have any questions or need additional information.

On a side note, no exceptions or errors are reported in the derby.log. All I see is the booting info and the shutdown info.

Regards,

Sai Pullabhotla
www.jMethods.com



On Fri, Jun 5, 2009 at 2:44 PM, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
Sai Pullabhotla wrote:
Since the customer restarted the app, by the time we got the derby.log, it was empty (I guess the log is overwritten everytime?).
It does unless unless you set this property: http://db.apache.org/derby/docs/10.5/ref/rrefproper13217.html#rrefproper13217

I will try to see if I can reproduce the error here and send you any additional logs.

It looks like you have a good understanding of what was going on at the time, so hopefully you can come up with a reproduction.   Even if you cannot, post what you have tried and perhaps someone can offer some suggestions or tweak it to pop the bug.

Kathey