db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: 50 transactions timing out with no CPU usage and no deadlocks
Date Mon, 26 Jan 2009 08:34:14 GMT
Blair Zajac wrote:
> Hello,
> I have a test case for my JDBC DAO layer that runs 50 concurrent threads 
> all inserting the same data to ensure that the DAO does not throw an 
> error if the data is already in the table (more details on the app 
> below).  After working a while Derby stops making progress, the 
> java process shows 0% CPU utilization and Derby does not report a 
> deadlock.  Running kill -QUIT on java shows all threads waiting on 
> something.  After a while, one transaction will timeout.
> Setting the lock timeout to -1 did not get the test to finish 
> successfully.  If I reduce the number of threads in the test to 10, then 
> Derby successfully completes.  The same exact code runs against 
> PostgreSQL and Oracle all 50 threads complete successfully.
> Connecting to the Derby server with ij and SELECTing on 
> SYSCS_DIAG.LOCK_TABLE shows that the transaction that has all the locks 
> that other transactions are waiting on is not in a WAIT state for any 
> other lock.  So according to this, it should be making progress, but 
> it's not.  Are there locks that the transaction can be waiting on that 
> aren't reported by SYSCS_DIAG.LOCK_TABLE.  Are there any other things to 
> look at?
> I have YourKit if that'll make it easier to help look at some internal 
> structures to see what's happening.  I can put a test case together that 
> replicates the behavior outside of our application and but it'll take a 
> little bit of coding and I can attach it later.

Hello Blair,

My only *guess* is that there might be a restructuring of a BTree going 
on, which is not correctly reported - and you might be experiencing a 
deadlock. To stop guessing and actually start understanding what's going 
on, it would be great if you could provide a standalone repro.
Such a repro is best handled by creating a bug report in Jira:

Other things to try:
  o Post the stack trace from the hang, preferably from a Derby debug 
build to get line numbers.
  o You don't say if you enabled "extended tracing". If not, see 
  o Download the patch for DERBY-2991, build Derby and see if it solves 
your problem.


> The application needs to treat a database more like a hash table than a 
> database for some of the data that needs to be stored.  The primary key 
> for the row is a MD5 hash of the other columns, so if there are multiple 
> clients connecting to the same Derby server and are given the same data, 
> which can happen due to load balancing to the application servers, 
> they'll all try to insert or update the same row.
> As background, below is the schema and code showing what I'm doing.  The 
> schema has four tables, three of which represent a set of facilities and 
> the fourth a location.

[ snip - sql/code ]

> If there's anything else I can provide, please let me know.
> Regards,
> Blair

View raw message