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 10.4.2.0 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:
https://issues.apache.org/jira/browse/DERBY
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
http://wiki.apache.org/db-derby/LockDebugging
o Download the patch for DERBY-2991, build Derby and see if it solves
your problem.
Regards,
--
Kristian
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
