5

I'd like to have a peek at Derby's database log; I don't mean the derby.log file, I'm talking about the binary log files in the /[database name]/log directory. Is there a tool that can display them in a human-readable format?

My reason for asking is that I'm using Apache Derby (version 10.6.1.0) for automatic integration tests, with the help of Maven Failsafe plug-in. Some tests execute transactional code that locks records (OpenJPA is used as an ORM tool). Sometimes, with a certain ordering of tests, it happens that a test waits forever for a lock, causing the build to hang. The same test, when run separately, passes. All the stranger thing is that every test drops, creates and fills all tables before it runs, so it's hard to see obvious reasons for this behaviour.

The problem has been worked around by putting the failing tests in a separate Failsafe execution; still, I'd like to read the log to see what's going on.

MaDa
  • 10,511
  • 9
  • 46
  • 84

1 Answers1

5

There do exist such tools, but they're quite low-level. Here's a place you can find them: https://issues.apache.org/jira/browse/DERBY-5195

Diagnosing locking problems such as these is very challenging; hopefully reading the logs will give you some clues. The logs will only contain information about update activity, so you will need to infer read activity using other means.

Another thing you might try is to see if you can augment your testing process to include invocations of the lock_table data (http://db.apache.org/derby/docs/10.8/devguide/cdevconcepts50894.html).

Probably either: (a) your ORM tool is running more/different code than you think it's running, or (b) your ORM tool is not expressing the transaction boundaries the way you think it is.

Best of luck!

Bryan Pendleton
  • 16,128
  • 3
  • 32
  • 56
  • Wow, I'm amazed how you knew about this one-class log formatter. You must be a Derby developer, aren't you? A pity is that it's so fresh that one must first build the trunk version of Derby oneself to compile the tool. Your second advice proved worthy, too, it seems the lock table is empty when my test stalls. It's likely a malfunction of OpenJPA, as in other "healthy" deadlocks it just times out after a minute – MaDa Jul 21 '11 at 09:13
  • If it's an application-level threading deadlock, such as within the ORM library, try using "Control-Break" or a similar technique to get a process-wide stack trace of all your Java threads, and there may be some clues there indicating where your threads are getting stuck. – Bryan Pendleton Jul 22 '11 at 14:45