Charles Lamb's Blog

Sometime soon, we'll be posting a new release of Berkeley DB Java Edition (JE) which will have some important bug fixes in it.  Probably the most important one has to do with JE configurations which place the environment directory on a remote file system.

A user reported some log corruption at one of their user's sites.  Whenever we see log corruption reported, we take it very seriously and investigate as thoroughly as possible.  So we groveled through the log files using tools like DbPrintLog and od (the unix Octal Dump tool).  This is generally a rather tedious business because it involves looking at very low level data in a rather non-user friendly format.  We typically refer to this kind of drill as "archeology" since we're trying to find out what happened in history with rather limited help (only the log and it may be corrupted).  In this particular case, we turned up a block of 0's in the middle of the log which happened to be aligned on a sector (512 byte) boundary.  Since JE does not do anything with sectors per say, this corruption raised red flags with us.  It turned out that the user was using a remote file system (NFS) for the environment directory.  Our FAQ on the topic is pretty specific about the limitations and requirements for using JE, and while we used to only talk about the impact of NFS on the je.lck file, we now discuss (or will very shortly) the ramifications of server-side caching.  To this end, as of JE 3.2.65, we've added a new flag -- je.log.useODSYNC -- which causes JE environment log files (the *.jdb files) to be opened with O_DSYNC.  This parameter should never be used when the environment directory lives on a local disk.  The parameter should always be used when the environment directory resides on a remote file system.

If you're reading this before JE 3.2.65 (or later) is available and you are using a remote file system to store your environment, let me know and I'll get you a pre-release with the parameter available in it. (charles.lamb at obvious.com).

JE 3.2.65 contains an important bug fix having to do with Two Phase Commit processing, as reported in this OTN Forum posting.  Specifically, if a transaction is prepared, but not committed, it is possible over the course of multiple recovery invocations (re-opening the JE environment) to have the transaction disappear (thereby preventing it from ever being committed).  If you're using distributed Two Phase Commit transactions, you'll want to pick up this release when it's available.