[Jdbm-general] commit() semantics, log vs. database files

[Chas E. <cem...@sn...>]

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  
file.

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  
it. :-)

Cheers,

- Chas