I'm intrigued by jdbm, and my initial evaluation of it has been pretty
positive so far. One thing has troubled me, though, and that's the
semantics of commit vs. close.
The javadoc for commit states:
Commit (make persistent) all changes since beginning of transaction.
It turns out though, that while TransactionManager.commit() does flush
data to disk, it (and therefore RecordManager.commit()) only flushes
data to the *log file*, not the database file. The log file doesn't
get sync'd up with the database file until the TransactionManager (and
therefore the RecordManager) are .close()'ed.
Indeed, the javadoc for TransactionManager.commit() says:
Commits the transaction to the log file.
That can be a very important distinction, something that probably
should be mentioned in the docs for RecordManager.commit().
I did eventually notice the TransactionManager.synchronizeLog()
method, which does migrate the changes in the log file to the database
Thankfully, the log file does appear to be automatically applied to
the database file the next time the database file is opened, but I'm
curious about the motivation behind the current semantics of commit,
given the general conception of what "committing" does in database
systems (e.g. flushes all changes to their "final resting place").
Further, absent calls to synchronizeLog(), one's application *will*
run out of memory if enough work is done with RecordManager in
between .close() or TransactionManager.synchronizeLog().
Of course, all of the hyperventilating above may be so much wind, in
the case that I'm simply missing something, or doing something wrong.
In that case, I'd love to be set straight.
Thanks for jdbm -- I'm looking forward to seeing what I can do with
Get latest updates about Open Source Projects, Conferences and News.