db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sai Pullabhotla <sai.pullabho...@jmethods.com>
Subject Re: Issue with SYSCS_UTIL.SYSCS_COMPRESS_ TABLE
Date Sat, 06 Jun 2009 23:01:29 GMT
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
>

Mime
View raw message