On Aug 13, 2010, at 5:18 PM, Jim Newsham wrote:
On 8/13/2010 4:02 AM, Kevin Day wrote:
Intersting - like I said, I haven't done much with jdbm2, but I definitely see why the different files might be needed - that could have a big impact on performance (not positive of that, but it does seem likely). Plus it drastically simplifies the paging logic.
The thought behind grabbing the db and lg files was that they may give us an idea of where the corruption originated from. But on further thinking, it would probably be better to know where the test app was executing at the time of termination immediately before the failure was found. The problem with this, of course, is that the failure may not be detected until several iterations after the cause (it depends on how thoroughly things get tested each iteration). I would want to see a full iteration through the records in the map at the beginning of each test cycle.
All that said, it seems that trying to track this particular issue in jdbm1 may not rise to a high level of priority... (esp if the problem doesn't occur in jdbm2). I hate to have you do a ton of testing, only to be told that it's not going to get fixed because there's a new kid on the block...
As a random aside, would you be able to package up the db files into a single file on successful close, then extract them on open? I know that may not work for your use-case, but thought I'd suggest it...
That might be a possibility, thanks for the idea. I'm going to weigh my options (jdbm1 or jdbm2) and think about it for a bit. Either I've got to make regular backups of jdbm1 to recover from corruption (probably on every startup or shutdown), or I've got to unpack/pack jdbm2 database files (on every startup/shutdown). Both of those are rather similar. I like that jdbm2 files are smaller overall; speed is not important for my case, since the use case is not data intensive.
Having a single database file was a significant concern when I chose jdbm over other options, so the notion that it's moving away from that in the newest development tree is unfortunate. Does anyone have any idea as to whether that's a permanent architectural decision (which I highly suspect given this discussion) or perhaps something that is configurable/optional/relaxable?