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?
- Chas
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Jdbm-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jdbm-general
