As of this release, inappropriate flags in the DBT structure will simply be ignored. This is intended to make it easy to, for example, retrieve a key/data pair and then use the data DBT as the key DBT for another database without having to reinitialize the flags in the DBT.
Previous Berkeley DB releases also required that threaded applications always set the DB_DBT_MALLOC or DB_DBT_USERMEM flags in DBT structures when retrieving key/data items. As of this release, specifying DB_DBT_MALLOC or DB_DBT_USERMEM is only required when using the non-cursor DB interfaces (e.g., DB->get). When using cursor interfaces (e.g., DBcursor->c_get), the flags are not required, as memory in which the key/data items are returned is allocated and maintained on a per-cursor basis.
This change is transparent to applications, but may NOT be transparent to local shell scripts and utilities.
The following statistics have been removed from the returned Btree statistical information: bt_freed, bt_pfxsaved, bt_split, bt_rootsplit, bt_fastsplit, bt_added, bt_deleted, bt_get, bt_cache_hit, bt_cache_miss. If any of these are sufficiently useful to application writers that they should be put back into the system, please let us know.
This change is NOT transparent to applications.
This change is potentially NOT transparent to applications.
There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a log write failure due to the disk being out of free space. The only way to recover from these failures is for the application to exit, run recovery of the Berkeley DB environment, and re-enter DB. (It is not strictly necessary that the application exit, although that is the only way to recover system resources, e.g., file descriptors and memory, currently allocated by Berkeley DB.)
In previous Berkeley DB releases, the only way an application could determine that a fatal error had occurred was to monitor Berkeley DB function return values, looking for unexpected ones, such as ENOSPC, or EPERM (which has historically been returned by Berkeley DB to indicate a potential underlying database corruption).
As of this release, we have added a new error return value, DB_RUNRECOVERY. This error can be returned by any Berkeley DB interface. If a fatal error occurs, DB_RUNRECOVERY will then be returned from all subsequent DB calls made by any threads or processes participating in the DB environment.
The EPERM error return no longer has a special meaning in Berkeley DB.
Optionally, applications may also specify a fatal-error callback function by setting the db_paniccall field of the DB_ENV structure before initializing the environment with db_appinit (DbEnv::appinit). This callback function will be called with two arguments: the DB_ENV structure associated with the environment and the errno value associated with the underlying error that caused the problem.
Applications can handle fatal errors in one of two ways: by checking for DB_RUNRECOVERY as part of their normal Berkeley DB error return checking, or, in applications that have no cleanup processing of their own, by simply exiting the application when the callback function is called.
We would be very interested in any comments that you'd care to make on this interface change, in particular, any comments on the sufficiency of the interface for your Berkeley DB application.
This change is NOT transparent to applications.
These methods are unneeded because the constructor with arguments, or the appinit() method, can be used to set this information.
These get methods accessed information that was never set by Berkeley DB.
Methods to get and set underlying lock identifiers in a DbLock have been removed, as lock identifiers should be completely opaque to the application.
The DbBtreeStat, DbLockStat, DbMpoolFStat, DbMpoolStat and DbTxnStat classes have been changed to allow direct access to their data members. DbLogStat is a new class.
These methods are unneeded because the constructor with arguments, or the appinit() method, can be used to set this information.
These get methods used to access information that was never set by Berkeley DB.
The DbEnv.get_java_version_string method has been removed, and the Java part of Berkeley DB no longer maintains its own version information.
Location | Contents |
---|---|
/usr/local/BerkeleyDB/bin | binaries |
/usr/local/BerkeleyDB/include | include files |
/usr/local/BerkeleyDB/lib | libraries |
/usr/local/BerkeleyDB/docs | HTML documentation |