The log file is actually cleared if things are shut down properly (only needed in the event of a crash) - just something to consider - theoretically, you could put the log file in a temp folder or something, but you have to make sure that if a crash occurs, the user immediately re-opens the app.
Ok. Understandable, thanks for entertaining the question.Feasibility for putting the log into the db file is not good at all - it would be a nightmare.
As you know, jdbm creates x.db, x.lg. By contrast, jdbm2 creates x.dbf0, x.dbf.t, x.dbr.0, x.dbr.t, x.idf.0, x.idf.t, x.idr.0, x.idr.t. The code in BaseRecordManager.reopen() hints at what these are used for:I haven't started playing with jdbm2 yet - if it's creating multiple files, I'd be interested if the jdbm2 lead has any comments on that.
For jdbm1, file corruption is something that we've seen in one very, very rare (and well defined) case. The latest code in SVN has a fix for the issue (it was related to recoverable write failures - namely if the disk ran out of space at one point, then suddenly had enough space). I'm pretty sure I commited a patch that fixes this, you can look at the SVN history notes to make sure.
In your code, you are comitting every single change (this shouldn't cause problems, I just wanted to point that out)...But outside of that, your code does look solid.
Other folks may need to weigh in here (Alex??), but here are my thoughts about how to maybe go about troubleshooting this:Is there any way for you to make backup copies of the db and lg files before you run each iteration, and halt the iterations as soon as you get the exception? I'm not positive that this will help, but this would at least give the db and log files that are required to make the failure happen.
You should be able to rename the lg file and actually bring up the db file by itself and not get errors. If that is indeed the case, then there is something about the log file that is resulting in the corruption, and we may be able to track that down.
Would you be willing to run the same test on the jdbm2 codebase? It would interesting to know if the problem exists in both places (if it does, it would give at least a hint of where the problem is coming from).