DB->close
-
-| Database Environment | Description |
|---|---|
| db_env_create | Create an environment handle |
| DBENV->close | Close an environment |
| DBENV->err | Error message with error string |
| DBENV->errx | Error message |
| DBENV->open | Open an environment |
| DBENV->remove | Remove an environment |
| DBENV->set_cachesize | Set the environment cache size |
| DBENV->set_data_dir | Set the environment data directory |
| DBENV->set_errcall | Set error message callback |
| DBENV->set_errfile | Set error message FILE |
| DBENV->set_errpfx | Set error message prefix |
| DBENV->set_feedback | Set feedback callback |
| DBENV->set_flags | Environment configuration |
| DBENV->set_mutexlocks | Turn off mutual exclusion locking |
| DBENV->set_paniccall | Set panic callback |
| DBENV->set_recovery_init | Set recovery initialization callback |
| DBENV->set_server | Establish server connection |
| DBENV->set_shm_key | Set system memory shared segment ID |
| DBENV->set_tmp_dir | Set the environment temporary file directory |
| DBENV->set_verbose | Set verbose messages |
| db_strerror | Error strings |
| db_version | Return version information |
| Database Operations | Description |
| db_create | Create a database handle |
| DB->close | Close a database |
| DB->del | Delete items from a database |
| DB->err | Error message with error string |
| DB->errx | Error message |
| DB->fd | Return a file descriptor from a database |
| DB->get | Get items from a database |
| DB->get_byteswapped | Return if the underlying database is in host order |
| DB->get_type | Return the database type |
| DB->join | Perform a database join on cursors |
| DB->key_range | Return estimate of key location |
| DB->open | Open a database |
| DB->put | Store items into a database |
| DB->remove | Remove a database |
| DB->rename | Rename a database |
| DB->set_append_recno | Set record append callback |
| DB->set_bt_compare | Set a Btree comparison function |
| DB->set_bt_minkey | Set the minimum number of keys per Btree page |
| DB->set_bt_prefix | Set a Btree prefix comparison function |
| DB->set_cachesize | Set the database cache size |
| DB->set_dup_compare | Set a duplicate comparison function |
| DB->set_errcall | Set error message callback |
| DB->set_errfile | Set error message FILE |
| DB->set_errpfx | Set error message prefix |
| DB->set_feedback | Set feedback callback |
| DB->set_flags | General database configuration |
| DB->set_h_ffactor | Set the Hash table density |
| DB->set_h_hash | Set a hashing function |
| DB->set_h_nelem | Set the Hash table size |
| DB->set_lorder | Set the database byte order |
| DB->set_malloc | Set a local space allocation function |
| DB->set_pagesize | Set the underlying database page size |
| DB->set_paniccall | Set panic callback |
| DB->set_q_extentsize | Set Queue database extent size |
| DB->set_re_delim | Set the variable-length record delimiter |
| DB->set_re_len | Set the fixed-length record length |
| DB->set_re_pad | Set the fixed-length record pad byte |
| DB->set_re_source | Set the backing Recno text file |
| DB->set_realloc | Set a local space allocation function |
| DB->stat | Return database statistics |
| DB->sync | Flush a database to stable storage |
| DB->upgrade | Upgrade a database |
| DB->verify | Verify/salvage a database |
| Database Cursors | Description |
| DB->cursor | Open a cursor into a database |
| DBcursor->c_close | Close a cursor |
| DBcursor->c_count | Return count of duplicates |
| DBcursor->c_del | Delete by cursor |
| DBcursor->c_dup | Duplicate a cursor |
| DBcursor->c_get | Retrieve by cursor |
| DBcursor->c_put | Store by cursor |
| Lock Manager | Description |
| DBENV->set_lk_conflicts | Set lock conflicts matrix |
| DBENV->set_lk_detect | Set automatic deadlock detection |
| DBENV->set_lk_max | Set maximum number of locks (Deprecated) |
| DBENV->set_lk_max_locks | Set maximum number of locks |
| DBENV->set_lk_max_lockers | Set maximum number of lockers |
| DBENV->set_lk_max_objects | Set maximum number of lock objects |
| lock_detect | Perform deadlock detection |
| lock_get | Acquire a lock |
| lock_id | Acquire a locker ID |
| lock_put | Release a lock |
| lock_stat | Return lock subsystem statistics |
| lock_vec | Acquire/release locks |
| Log Manager | Description |
| DBENV->set_lg_bsize | Set log buffer size |
| DBENV->set_lg_dir | Set the environment logging directory |
| DBENV->set_lg_max | Set log file size |
| log_archive | List log and database files |
| log_compare | Compare two Log Sequence Numbers |
| log_file | Map Log Sequence Numbers to log files |
| log_flush | Flush log records |
| log_get | Get a log record |
| log_put | Write a log record |
| log_register | Register a file name with the log manager |
| log_stat | Return log subsystem statistics |
| log_unregister | Unregister a file name with the log manager |
| Buffer Pool | Description |
| DBENV->set_cachesize | Set the environment cache size |
| DBENV->set_mp_mmapsize | Set maximum mapped-in database file size |
| memp_fclose | Close a file in a buffer pool |
| memp_fget | Get a page from a file in a buffer pool |
| memp_fopen | Open a file in a buffer pool |
| memp_fput | Return a page to a buffer pool |
| memp_fset | Modify meta information for buffer pool page |
| memp_fsync | Flush pages from a file in a buffer pool |
| memp_register | Register input/output functions for a file in a buffer pool |
| memp_stat | Return buffer pool statistics |
| memp_sync | Flush pages from a buffer pool |
| memp_trickle | Trickle flush pages from a buffer pool |
| Transaction Manager | Description |
| DBENV->set_tx_max | Set maximum number of transactions |
| DBENV->set_tx_recover | Set transaction abort recover function |
| DBENV->set_tx_timestamp | Set recovery timestamp |
| txn_abort | Abort a transaction |
| txn_begin | Begin a transaction |
| txn_checkpoint | Checkpoint the transaction subsystem |
| txn_commit | Commit a transaction |
| txn_id | Return a transaction ID |
| txn_prepare | Prepare a transaction for commit |
| txn_stat | Return transaction subsystem statistics |
| Historic Interfaces | Description |
| dbm | UNIX Dbm/Ndbm Interfaces |
| hsearch | UNIX Hsearch Interfaces |
| Data Structures | Description |
| DBT | DBT structures |
| DB_LSN | DB_LSN structures |
| DB Library Configuration | Description |
| db_env_set_pageyield | Yield the processor on each page access |
| db_env_set_panicstate | Reset panic state |
| db_env_set_region_init | Fault in shared regions on initial access |
| db_env_set_tas_spins | Set the number of test-and-set spins |
| DB System Call Configuration | Description |
| db_env_set_func_close | Replace underlying Berkeley DB system interfaces |
| db_env_set_func_dirfree | |
| db_env_set_func_dirlist | |
| db_env_set_func_exists | |
| db_env_set_func_free | |
| db_env_set_func_fsync | |
| db_env_set_func_ioinfo | |
| db_env_set_func_malloc | |
| db_env_set_func_map | |
| db_env_set_func_open | |
| db_env_set_func_read | |
| db_env_set_func_realloc | |
| db_env_set_func_rename | |
| db_env_set_func_seek | |
| db_env_set_func_sleep | |
| db_env_set_func_unlink | |
| db_env_set_func_unmap | |
| db_env_set_func_write | |
| db_env_set_func_yield |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/c_pindex.html b/bdb/docs/api_c/c_pindex.html deleted file mode 100644 index 725bf0068a9..00000000000 --- a/bdb/docs/api_c/c_pindex.html +++ /dev/null @@ -1,530 +0,0 @@ - -
-| configuring Berkeley DB | 1.85 API compatibility |
| building a utility to dump Berkeley DB | 1.85 databases |
| Upgrading to release | 2.0 |
| Upgrading to release | 3.0 |
| Upgrading to release | 3.1 |
| Upgrading to release | 3.2 |
| selecting an | access method |
| access methods | |
| AIX | |
| data | alignment |
| programmatic | APIs |
| utility to | archive log files |
| berkeley_db_svc | |
| building for UNIX | |
| building for UNIX FAQ | |
| building for VxWorks | |
| building for VxWorks FAQ | |
| building for Win32 | |
| building for Windows FAQ | |
| selecting a | byte order |
| byte ordering | |
| configuring the | C++ API |
| flushing the database | cache |
| selecting a | cache size |
| catastrophic recovery | |
| Patches, Updates and | Change logs |
| utility to take | checkpoints |
| memp_fopen | clear_len |
| closing a cursor | |
| closing a database | |
| specifying a Btree | comparison function |
| changing | compile or load options |
| Concurrent Data Store | |
| configuring Berkeley DB for UNIX systems | |
| recovering | corrupted databases |
| counting data items for a key | |
| closing a | cursor |
| deleting records with a | cursor |
| duplicating a | cursor |
| retrieving records with a | cursor |
| storing records with a | cursor |
| cursor stability | |
| database | cursors |
| DBT | data |
| utility to upgrade | database files |
| utility to verify | database files |
| DBcursor->c_put | DB_AFTER |
| DB->verify | DB_AGGRESSIVE |
| DB->put | DB_APPEND |
| log_archive | DB_ARCH_ABS |
| log_archive | DB_ARCH_DATA |
| db_archive | |
| log_archive | DB_ARCH_LOG |
| DBcursor->c_put | DB_BEFORE |
| DB->stat | DB_CACHED_COUNTS |
| DBENV->set_flags | DB_CDB_ALLDB |
| log_get | DB_CHECKPOINT |
| log_put | DB_CHECKPOINT |
| db_checkpoint | |
| db_env_create | DB_CLIENT |
| File naming | DB_CONFIG |
| DB->get | DB_CONSUME |
| DB->get | DB_CONSUME_WAIT |
| db_create | |
| DB->open | DB_CREATE |
| DBENV->open | DB_CREATE |
| memp_fopen | DB_CREATE |
| log_put | DB_CURLSN |
| DBcursor->c_get | DB_CURRENT |
| DBcursor->c_put | DB_CURRENT |
| log_get | DB_CURRENT |
| DBcursor->c_close | |
| DBcursor->c_count | |
| DBcursor->c_del | |
| DBcursor->c_dup | |
| DBcursor->c_get | |
| DBcursor->c_put | |
| DBT | DB_DBT_MALLOC |
| DBT | DB_DBT_PARTIAL |
| DBT | DB_DBT_REALLOC |
| DBT | DB_DBT_USERMEM |
| db_deadlock | |
| db_dump | |
| DB->set_flags | DB_DUP |
| DB->set_flags | DB_DUPSORT |
| DB->upgrade | DB_DUPSORT |
| db_env_create | |
| DBENV->close | |
| DBENV->err | |
| DBENV->open | |
| DBENV->remove | |
| DBENV->set_cachesize | |
| DBENV->set_data_dir | |
| DBENV->set_errcall | |
| DBENV->set_errfile | |
| DBENV->set_errpfx | |
| DBENV->set_feedback | |
| DBENV->set_flags | |
| DBENV->set_lg_bsize | |
| DBENV->set_lg_dir | |
| DBENV->set_lg_max | |
| DBENV->set_lk_conflicts | |
| DBENV->set_lk_detect | |
| DBENV->set_lk_max | |
| DBENV->set_lk_max_lockers | |
| DBENV->set_lk_max_locks | |
| DBENV->set_lk_max_objects | |
| DBENV->set_mp_mmapsize | |
| DBENV->set_mutexlocks | |
| DBENV->set_paniccall | |
| DBENV->set_recovery_init | |
| DBENV->set_server | |
| DBENV->set_shm_key | |
| DBENV->set_tmp_dir | |
| DBENV->set_tx_max | |
| DBENV->set_tx_recover | |
| DBENV->set_tx_timestamp | |
| DBENV->set_verbose | |
| db_env_set_func_close | |
| db_env_set_func_dirfree | |
| db_env_set_func_dirlist | |
| db_env_set_func_exists | |
| db_env_set_func_free | |
| db_env_set_func_fsync | |
| db_env_set_func_ioinfo | |
| db_env_set_func_malloc | |
| db_env_set_func_map | |
| db_env_set_func_open | |
| db_env_set_func_read | |
| db_env_set_func_realloc | |
| db_env_set_func_rename | |
| db_env_set_func_seek | |
| db_env_set_func_sleep | |
| db_env_set_func_unlink | |
| db_env_set_func_unmap | |
| db_env_set_func_write | |
| db_env_set_func_yield | |
| db_env_set_pageyield | |
| db_env_set_panicstate | |
| db_env_set_region_init | |
| db_env_set_tas_spins | |
| DB->open | DB_EXCL |
| DBcursor->c_get | DB_FIRST |
| log_get | DB_FIRST |
| log_put | DB_FLUSH |
| DBENV->remove | DB_FORCE |
| txn_checkpoint | DB_FORCE |
| DB->get | DB_GET_BOTH |
| DBcursor->c_get | DB_GET_BOTH |
| DBcursor->c_get | DB_GET_RECNO |
| DB->close | |
| DB->cursor | |
| DB->del | |
| DB->fd | |
| DB->get | |
| DB->get_byteswapped | |
| DB->get_type | |
| DB->join | |
| DB->key_range | |
| DB->open | |
| DB->put | |
| DB->remove | |
| DB->rename | |
| DB->set_append_recno | |
| DB->set_bt_compare | |
| DB->set_bt_minkey | |
| DB->set_bt_prefix | |
| DB->set_cachesize | |
| DB->set_dup_compare | |
| DB->set_errcall | |
| DB->set_errfile | |
| DB->set_errpfx | |
| DB->set_feedback | |
| DB->set_flags | |
| DB->set_h_ffactor | |
| DB->set_h_hash | |
| DB->set_h_nelem | |
| DB->set_lorder | |
| DB->set_malloc | |
| DB->set_pagesize | |
| DB->set_paniccall | |
| DB->set_q_extentsize | |
| DB->set_realloc | |
| DB->set_re_delim | |
| DB->set_re_len | |
| DB->set_re_pad | |
| DB->set_re_source | |
| DB->stat | |
| DB->sync | |
| DB->upgrade | |
| DB->verify | |
| File naming | DB_HOME |
| File naming | db_home |
| DB->close | DB_INCOMPLETE |
| DBENV->open | DB_INIT_CDB |
| DBENV->open | DB_INIT_LOCK |
| DBENV->open | DB_INIT_LOG |
| DBENV->open | DB_INIT_MPOOL |
| DBENV->open | DB_INIT_TXN |
| DBENV->open | DB_JOINENV |
| DB->join | DB_JOIN_ITEM |
| DBcursor->c_get | DB_JOIN_ITEM |
| DB->join | DB_JOIN_NOSORT |
| Error returns to applications | DB_KEYEMPTY |
| DBcursor->c_put | DB_KEYFIRST |
| DBcursor->c_put | DB_KEYLAST |
| DBcursor->c_get | DB_LAST |
| log_get | DB_LAST |
| db_load | |
| lock_detect | DB_LOCK_CONFLICT |
| Error returns to applications | DB_LOCK_DEADLOCK |
| DBENV->set_lk_detect | DB_LOCK_DEFAULT |
| DBENV->open | DB_LOCKDOWN |
| lock_vec | DB_LOCK_GET |
| lock_get | DB_LOCK_NOTGRANTED |
| lock_vec | DB_LOCK_NOTGRANTED |
| Error returns to applications | DB_LOCK_NOTGRANTED |
| lock_get | DB_LOCK_NOWAIT |
| lock_vec | DB_LOCK_NOWAIT |
| DBENV->set_lk_detect | DB_LOCK_OLDEST |
| lock_vec | DB_LOCK_PUT |
| lock_vec | DB_LOCK_PUT_ALL |
| lock_vec | DB_LOCK_PUT_OBJ |
| DBENV->set_lk_detect | DB_LOCK_RANDOM |
| DBENV->set_lk_detect | DB_LOCK_YOUNGEST |
| DB_LSN | |
| dbm/ndbm | |
| memp_fput | DB_MPOOL_CLEAN |
| memp_fset | DB_MPOOL_CLEAN |
| memp_fget | DB_MPOOL_CREATE |
| memp_fput | DB_MPOOL_DIRTY |
| memp_fset | DB_MPOOL_DIRTY |
| memp_fput | DB_MPOOL_DISCARD |
| memp_fset | DB_MPOOL_DISCARD |
| memp_fget | DB_MPOOL_LAST |
| memp_fget | DB_MPOOL_NEW |
| DBcursor->c_get | DB_NEXT |
| log_get | DB_NEXT |
| DBcursor->c_get | DB_NEXT_DUP |
| DBcursor->c_get | DB_NEXT_NODUP |
| DB->put | DB_NODUPDATA |
| DBcursor->c_put | DB_NODUPDATA |
| DB->open | DB_NOMMAP |
| DBENV->set_flags | DB_NOMMAP |
| memp_fopen | DB_NOMMAP |
| DB->verify | DB_NOORDERCHK |
| DB->put | DB_NOOVERWRITE |
| DBENV->set_server | DB_NOSERVER |
| DBENV->set_server | DB_NOSERVER_ID |
| DB->close | DB_NOSYNC |
| Error returns to applications | DB_NOTFOUND |
| DB->open | DB_OLD_VERSION |
| DB->upgrade | DB_OLD_VERSION |
| DB->verify | DB_ORDERCHKONLY |
| DBcursor->c_dup | DB_POSITION |
| DBcursor->c_get | DB_PREV |
| log_get | DB_PREV |
| DBcursor->c_get | DB_PREV_NODUP |
| db_printlog | |
| DBENV->open | DB_PRIVATE |
| DB->open | DB_RDONLY |
| memp_fopen | DB_RDONLY |
| DB->set_flags | DB_RECNUM |
| DB->stat | DB_RECORDCOUNT |
| DBENV->open | DB_RECOVER |
| DBENV->set_feedback | DB_RECOVER |
| db_recover | |
| DBENV->open | DB_RECOVER_FATAL |
| DB->set_flags | DB_RENUMBER |
| DB->set_flags | DB_REVSPLITOFF |
| DB->get | DB_RMW |
| DB->join | DB_RMW |
| DBcursor->c_get | DB_RMW |
| Error returns to applications | DB_RUNRECOVERY |
| DB->verify | DB_SALVAGE |
| DBcursor->c_get | DB_SET |
| log_get | DB_SET |
| DBcursor->c_get | DB_SET_RANGE |
| DB->get | DB_SET_RECNO |
| DBcursor->c_get | DB_SET_RECNO |
| DB->set_flags | DB_SNAPSHOT |
| db_stat | |
| db_strerror | |
| DBENV->open | DB_SYSTEM_MEM |
| DB->open | DB_THREAD |
| DBENV->open | DB_THREAD |
| DB->open | DB_TRUNCATE |
| DBENV->set_tx_recover | DB_TXN_ABORT |
| DBENV->set_tx_recover | DB_TXN_BACKWARD_ROLL |
| DBENV->set_tx_recover | DB_TXN_FORWARD_ROLL |
| DBENV->set_flags | DB_TXN_NOSYNC |
| txn_begin | DB_TXN_NOSYNC |
| txn_commit | DB_TXN_NOSYNC |
| txn_begin | DB_TXN_NOWAIT |
| txn_begin | DB_TXN_SYNC |
| txn_commit | DB_TXN_SYNC |
| DB->set_feedback | DB_UPGRADE |
| db_upgrade | |
| DBENV->open | DB_USE_ENVIRON |
| DBENV->remove | DB_USE_ENVIRON |
| DBENV->open | DB_USE_ENVIRON_ROOT |
| DBENV->remove | DB_USE_ENVIRON_ROOT |
| DBENV->set_verbose | DB_VERB_CHKPOINT |
| DBENV->set_verbose | DB_VERB_DEADLOCK |
| DBENV->set_verbose | DB_VERB_RECOVERY |
| DBENV->set_verbose | DB_VERB_WAITSFOR |
| DB->set_feedback | DB_VERIFY |
| db_verify | |
| db_version | |
| DB->cursor | DB_WRITECURSOR |
| db_create | DB_XA_CREATE |
| deadlocks | |
| utility to detect | deadlocks |
| debugging applications | |
| deleting records | |
| deleting records with a cursor | |
| Configuring Berkeley DB | --disable-bigfile |
| disk space requirements | |
| DBT | dlen |
| DBT | doff |
| utility to | dump databases as text files |
| duplicate data items | |
| duplicating a cursor | |
| configuring | dynamic shared libraries |
| Configuring Berkeley DB | --enable-compat185 |
| Configuring Berkeley DB | --enable-cxx |
| Configuring Berkeley DB | --enable-debug |
| Configuring Berkeley DB | --enable-debug_rop |
| Configuring Berkeley DB | --enable-debug_wop |
| Configuring Berkeley DB | --enable-diagnostic |
| Configuring Berkeley DB | --enable-dump185 |
| Configuring Berkeley DB | --enable-dynamic |
| Configuring Berkeley DB | --enable-java |
| Configuring Berkeley DB | --enable-posixmutexes |
| Configuring Berkeley DB | --enable-rpc |
| Configuring Berkeley DB | --enable-shared |
| Configuring Berkeley DB | --enable-tcl |
| Configuring Berkeley DB | --enable-test |
| Configuring Berkeley DB | --enable-uimutexes |
| Configuring Berkeley DB | --enable-umrw |
| byte | endian |
| database | environment |
| environment variables | |
| error handling | |
| error name space | |
| error returns | |
| /etc/magic | |
| selecting a Queue | extent size |
| Java | FAQ |
| Tcl | FAQ |
| configuring without large | file support |
| file utility | |
| memp_fopen | fileid |
| recovery and | filesystem operations |
| remote | filesystems |
| page | fill factor |
| FreeBSD | |
| Berkeley DB | free-threaded handles |
| memp_fopen | ftype |
| specifying a database | hash |
| hash table size | |
| HP-UX | |
| hsearch | |
| installing Berkeley DB for UNIX systems | |
| interface compatibility | |
| IRIX | |
| configuring the | Java API |
| Java compatibility | |
| Java configuration | |
| Java FAQ | |
| logical | join |
| key/data pairs | |
| retrieved | key/data permanence |
| database | limits |
| Linux | |
| changing compile or | load options |
| utility to | load text files into databases |
| lock_vec | lock |
| standard | lock modes |
| lock_detect | |
| lock_get | |
| lock_id | |
| page-level | locking |
| two-phase | locking |
| locking and non-Berkeley DB applications | |
| locking configuration | |
| locking conventions | |
| Berkeley DB Concurrent Data Store | locking conventions |
| locking introduction | |
| sizing the | locking subsystem |
| locking without transactions | |
| lock_put | |
| lock_stat | |
| lock_vec | |
| log file limits | |
| log file removal | |
| utility to display | log files as text |
| log_archive | |
| log_compare | |
| log_file | |
| log_flush | |
| log_get | |
| logging configuration | |
| logging introduction | |
| log_put | |
| log_register | |
| log_stat | |
| log_unregister | |
| memp_fopen | lsn_offset |
| memory pool configuration | |
| memp_fclose | |
| memp_fget | |
| memp_fopen | |
| memp_fput | |
| memp_fset | |
| memp_fsync | |
| memp_register | |
| memp_stat | |
| memp_sync | |
| memp_trickle | |
| lock_vec | mode |
| Berkeley DB library | name spaces |
| file | naming |
| retrieving Btree records by | number |
| lock_vec | obj |
| lock_vec | op |
| opening a database | |
| OSF/1 | |
| selecting a | page size |
| partial record storage and retrieval | |
| Patches, Updates and Change logs | |
| Perl | |
| retrieved key/data | permanence |
| memp_fopen | pgcookie |
| Sleepycat Software's Berkeley DB | products |
| QNX | |
| logical | record number format |
| logical | record numbers |
| managing | record-based databases |
| logically renumbering | records |
| utility to | recover database environments |
| Berkeley DB | recoverability |
| retrieving records | |
| retrieving records with a cursor | |
| RPC client | |
| configuring a | RPC client/server |
| utility to support | RPC client/server |
| RPC server | |
| database | salvage |
| SCO | |
| Berkeley DB handle | scope |
| security | |
| Sendmail | |
| configuring | shared libraries |
| shared libraries | |
| application | signal handling |
| DBT | size |
| Sleepycat Software | |
| Solaris | |
| source code layout | |
| cursor | stability |
| database | statistics |
| utility to display database and environment | statistics |
| storing records | |
| storing records with a cursor | |
| SunOS | |
| loading Berkeley DB with | Tcl |
| using Berkeley DB with | Tcl |
| configuring the | Tcl API |
| Tcl API programming notes | |
| Tcl FAQ | |
| configuring the | test suite |
| running the | test suite |
| running the | test suite under UNIX |
| running the | test suite under Windows |
| text backing files | |
| loading | text into databases |
| dumping/loading | text to/from databases |
| building | threaded applications |
| transaction configuration | |
| transaction limits | |
| administering | transaction protected applications |
| archival in | transaction protected applications |
| checkpoints in | transaction protected applications |
| deadlock detection in | transaction protected applications |
| recovery in | transaction protected applications |
| transaction throughput | |
| Transactional Data Store | |
| Berkeley DB and | transactions |
| nested | transactions |
| configuring Berkeley DB with the | Tuxedo System |
| txn_abort | |
| txn_begin | |
| txn_checkpoint | |
| txn_commit | |
| txn_id | |
| txn_prepare | |
| txn_stat | |
| DBT | ulen |
| Ultrix | |
| building for | UNIX FAQ |
| configuring Berkeley DB for | UNIX systems |
| Patches, | Updates and Change logs |
| utility to | upgrade database files |
| upgrading databases | |
| utilities | |
| database | verification |
| utility to | verify database files |
| building for | VxWorks FAQ |
| VxWorks notes | |
| running the test suite under | Windows |
| building for | Windows FAQ |
| Windows notes | |
| Configuring Berkeley DB | --with-tcl=DIR |
| XA Resource Manager |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_close.html b/bdb/docs/api_c/db_close.html deleted file mode 100644 index f6c763c5b12..00000000000 --- a/bdb/docs/api_c/db_close.html +++ /dev/null @@ -1,119 +0,0 @@ - - - - -
-
-DB->close- |
-
-
- |
-#include <db.h> --int -DB->close(DB *db, u_int32_t flags); -
The DB->close function flushes any cached database information to disk, -closes any open cursors, frees any allocated resources, and closes any -underlying files. Since key/data pairs are cached in memory, failing to -sync the file with the DB->close or DB->sync function may result -in inconsistent or lost information. -
The flags parameter must be set to 0 or the following value: -
The DB_NOSYNC flag is a dangerous option. It should only be set -if the application is doing logging (with transactions) so that the -database is recoverable after a system or application crash, or if the -database is always generated from scratch after any system or application -crash. -
It is important to understand that flushing cached information to disk -only minimizes the window of opportunity for corrupted data. -While unlikely, it is possible for database corruption to happen if a -system or application crash occurs while writing data to the database. -To ensure that database corruption never occurs, applications must either: -use transactions and logging with automatic recovery, use logging and -application-specific recovery, or edit a copy of the database, -and, once all applications using the database have successfully called -DB->close, atomically replace the original database with the -updated copy. -
When multiple threads are using the Berkeley DB handle concurrently, only a single -thread may call the DB->close function. -
Once DB->close has been called, regardless of its return, the -DB handle may not be accessed again. - -
The DB->close function returns a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if the underlying database still has -dirty pages in the cache. (The only reason to return -DB_INCOMPLETE is if another thread of control was writing pages -in the underlying database file at the same time as the -DB->close function was called. For this reason, a return of -DB_INCOMPLETE can normally be ignored, or, in cases where it is -a possible return value, the DB_NOSYNC option should probably -have been specified.) -
The DB->close function returns a non-zero error value on failure and 0 on success. -
The DB->close function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->close function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_create.html b/bdb/docs/api_c/db_create.html deleted file mode 100644 index c1fd3fca10b..00000000000 --- a/bdb/docs/api_c/db_create.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - -
-
-db_create- |
-
-
- |
-#include <db.h> --int -db_create(DB **dbp, DB_ENV *dbenv, u_int32_t flags); -
The db_create function creates a DB structure which is the -handle for a Berkeley DB database. A pointer to this structure is returned -in the memory referenced by db. -
If the dbenv argument is NULL, the database is standalone, i.e., -it is not part of any Berkeley DB environment. -
If the dbenv argument is not NULL, the database is created within -the specified Berkeley DB environment. The database access methods -automatically make calls to the other subsystems in Berkeley DB based on the -enclosing environment. For example, if the environment has been -configured to use locking, then the access methods will automatically -acquire the correct locks when reading and writing pages of the database. -
The flags parameter must be set to 0 or one of the following -values: -
The DB handle contains a special field, "app_private", which -is declared as type "void *". This field is provided for the use of -the application program. It is initialized to NULL and is not further -used by Berkeley DB in any way. -
The db_create function returns a non-zero error value on failure and 0 on success. -
The db_create function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the db_create function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_cursor.html b/bdb/docs/api_c/db_cursor.html deleted file mode 100644 index 1fb6616ab63..00000000000 --- a/bdb/docs/api_c/db_cursor.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - -
-
-DB->cursor- |
-
-
- |
-#include <db.h> --int -DB->cursor(DB *db, - DB_TXN *txnid, DBC **cursorp, u_int32_t flags); -
The DB->cursor function -creates a cursor and copies a pointer to it into the memory referenced -by cursorp. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -txn_begin, otherwise, NULL. -
If transaction protection is enabled, cursors must be opened and closed -within the context of a transaction, and the txnid parameter -specifies the transaction context in which the cursor may be used. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB->cursor function returns a non-zero error value on failure and 0 on success. -
The DB->cursor function may fail and return a non-zero error for the following conditions: -
The DB->cursor function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->cursor function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_del.html b/bdb/docs/api_c/db_del.html deleted file mode 100644 index b273d29fd14..00000000000 --- a/bdb/docs/api_c/db_del.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - -
-
-DB->del- |
-
-
- |
-#include <db.h> --int -DB->del(DB *db, DB_TXN *txnid, DBT *key, u_int32_t flags); -
The DB->del function removes key/data pairs from the database. The -key/data pair associated with the specified key is discarded from -the database. In the presence of duplicate key values, all records -associated with the designated key will be discarded. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -txn_begin, otherwise, NULL. -
The flags parameter is currently unused, and must be set to 0. -
The DB->del function returns a non-zero error value on failure, 0 on success, and DB_NOTFOUND if the specified key did not exist in -the file. -
The DB->del function may fail and return a non-zero error for the following conditions: -
The DB->del function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->del function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_err.html b/bdb/docs/api_c/db_err.html deleted file mode 100644 index 1eae12fabf0..00000000000 --- a/bdb/docs/api_c/db_err.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - -
-
-DBENV->err- |
-
-
- |
-#include <db.h> --void -DBENV->err(DB_ENV *dbenv, int error, const char *fmt, ...); -
-void -DBENV->errx(DB_ENV *dbenv, const char *fmt, ...); -
-void -DB->err(DB *db, int error, const char *fmt, ...); -
-void -DB->errx(DB *db, const char *fmt, ...); -
The DBENV->err, DBENV->errx, DB->err and -DB->errx functions provide error messaging functionality for -applications written using the Berkeley DB library. -
The DBENV->err function constructs an error message consisting of the -following elements: -
--
-- An optional prefix string
- If no error callback function has been set using the -DBENV->set_errcall function, any prefix string specified using the -DBENV->set_errpfx function, followed by two separating characters: a colon -and a <space> character. -
- An optional printf-style message
- The supplied message fmt, if non-NULL, where the ANSI C X3.159-1989 (ANSI C) -printf function specifies how subsequent arguments are converted for -output. -
- A separator
- Two separating characters: a colon and a <space> character. -
- A standard error string
- The standard system or Berkeley DB library error string associated with the -error value, as returned by the db_strerror function. -
This constructed error message is then handled as follows: -
--If an error callback function has been set (see DB->set_errcall -and DBENV->set_errcall), that function is called with two -arguments: any prefix string specified (see DB->set_errpfx and -DBENV->set_errpfx), and the error message. -
If a C library FILE * has been set (see DB->set_errfile and -DBENV->set_errfile), the error message is written to that output -stream. -
If none of these output options has been configured, the error message -is written to stderr, the standard error output stream.
The DBENV->errx and DB->errx functions perform identically to the -DBENV->err and DB->err functions except that they do not append -the final separator characters and standard error string to the error -message. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_fd.html b/bdb/docs/api_c/db_fd.html deleted file mode 100644 index 2a385c1b3d1..00000000000 --- a/bdb/docs/api_c/db_fd.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-DB->fd- |
-
-
- |
-#include <db.h> --int -DB->fd(DB *db, int *fdp); -
The DB->fd function -copies a file descriptor representative of the underlying database into -the memory referenced by fdp. A file descriptor referencing the -same file will be returned to all processes that call DB->open with -the same file argument. This file descriptor may be safely used -as an argument to the fcntl(2) and flock(2) locking -functions. The file descriptor is not necessarily associated with any of -the underlying files actually used by the access method. -
The DB->fd function only supports a coarse-grained form of locking. -Applications should use the lock manager where possible. -
The DB->fd function returns a non-zero error value on failure and 0 on success. -
The DB->fd function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->fd function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_get.html b/bdb/docs/api_c/db_get.html deleted file mode 100644 index c6cc3fcce43..00000000000 --- a/bdb/docs/api_c/db_get.html +++ /dev/null @@ -1,156 +0,0 @@ - - - - -
-
-DB->get- |
-
-
- |
-#include <db.h> --int -DB->get(DB *db, - DB_TXN *txnid, DBT *key, DBT *data, u_int32_t flags); -
The DB->get function retrieves key/data pairs from the database. The -address -and length of the data associated with the specified key are -returned in the structure referenced by data. -
In the presence of duplicate key values, DB->get will return the -first data item for the designated key. Duplicates are sorted by insert -order except where this order has been overridden by cursor operations. -Retrieval of duplicates requires the use of cursor operations. -See DBcursor->c_get for details. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -txn_begin, otherwise, NULL. -
The flags parameter must be set to 0 or one of the following -values: -
The data field of the specified key -must be a pointer to a logical record number (i.e., a db_recno_t). -This record number determines the record to be retrieved. -
For DB_SET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM flag. -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
As the DB->get interface will not hold locks across -Berkeley DB interface calls in non-transactional environments, the -DB_RMW flag to the DB->get call is only meaningful in -the presence of transactions. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -the DB->get function returns DB_KEYEMPTY. -
Otherwise, if the requested key is not in the database, the -DB->get function returns DB_NOTFOUND. -
Otherwise, the DB->get function returns a non-zero error value on failure and 0 on success. -
The DB->get function may fail and return a non-zero error for the following conditions: -
A record number of 0 was specified. -
The DB_THREAD flag was specified to the -DB->open function and none of the DB_DBT_MALLOC, -DB_DBT_REALLOC or DB_DBT_USERMEM flags were set in the -DBT. -
The DB->get function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->get function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_get_byteswapped.html b/bdb/docs/api_c/db_get_byteswapped.html deleted file mode 100644 index 205ddb79467..00000000000 --- a/bdb/docs/api_c/db_get_byteswapped.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-DB->get_byteswapped- |
-
-
- |
-#include <db.h> --int -DB->get_byteswapped(DB *db); -
The DB->get_byteswapped function returns -0 -if the underlying database files were created on an architecture -of the same byte order as the current one, and -1 -if they were not (i.e., big-endian on a little-endian machine or -vice-versa). This field may be used to determine if application -data needs to be adjusted for this architecture or not. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_get_type.html b/bdb/docs/api_c/db_get_type.html deleted file mode 100644 index a1905c782e4..00000000000 --- a/bdb/docs/api_c/db_get_type.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - -
-
-DB->get_type- |
-
-
- |
-#include <db.h> --DBTYPE -DB->get_type(DB *db); -
The DB->get_type function returns the type of the underlying access method -(and file format). It returns one of DB_BTREE, -DB_HASH or DB_RECNO. This value may be used to -determine the type of the database after a return from DB->open -with the type argument set to DB_UNKNOWN. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_join.html b/bdb/docs/api_c/db_join.html deleted file mode 100644 index 13fe95d84d7..00000000000 --- a/bdb/docs/api_c/db_join.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - -
-
-DB->join- |
-
-
- |
-#include <db.h> --int -DB->join(DB *primary, - DBC **curslist, DBC **dbcp, u_int32_t flags); -
The DB->join function creates a specialized cursor for use in performing -joins on secondary indexes. For information on how to organize your data -to use this functionality, see Logical -join. -
The primary argument contains the DB handle of the primary -database, which is keyed by the data values found in entries in the -curslist. -
The curslist argument contains a NULL terminated array of cursors. -Each cursor must have been initialized to reference the key on which the -underlying database should be joined. Typically, this initialization is done -by a DBcursor->c_get call with the DB_SET flag specified. Once the -cursors have been passed as part of a curslist, they should not -be accessed or modified until the newly created join cursor has been closed, -or else inconsistent results may be returned. -
Joined values are retrieved by doing a sequential iteration over the first -cursor in the curslist argument, and a nested iteration over each -secondary cursor in the order they are specified in the curslist -argument. This requires database traversals to search for the current -datum in all the cursors after the first. For this reason, the best join -performance normally results from sorting the cursors from the one that -references the least number of data items to the one that references the -most. By default, DB->join does this sort on behalf of its caller. -
The flags parameter must be set to 0 or the following value: -
A newly created cursor is returned in the memory location referenced by -dbcp and has the standard cursor functions: -
The flags parameter must be set to 0 or the following value: -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
For the returned join cursor to be used in a transaction protected manner, -the cursors listed in curslist must have been created within the -context of the same transaction. -
The DB->join function returns a non-zero error value on failure and 0 on success. -
The DB->join function may fail and return a non-zero error for the following conditions: -
The DBcursor->c_put or DBcursor->c_del functions were called. -
The DB->join function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->join function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_key_range.html b/bdb/docs/api_c/db_key_range.html deleted file mode 100644 index 1e3c4c91f99..00000000000 --- a/bdb/docs/api_c/db_key_range.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - -
-
-DB->key_range- |
-
-
- |
-#include <db.h> --int -DB->key_range(DB *db, DB_TXN *txnid, - DBT *key, DB_KEY_RANGE *key_range, u_int32_t flags); -
The DB->key_range function returns an estimate of the proportion of keys -that are less than, equal to and greater than the specified key. The -underlying database must be of type Btree. -
The information is returned in the key_range argument, which -contains three elements of type double, less, equal and -greater. Values are in the range of 0 to 1, e.g., if the field -less is 0.05, that indicates that 5% of the keys in the database -are less than the key argument. The value for equal will be zero -if there is no matching key and non-zero otherwise. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -txn_begin, otherwise, NULL. -The DB->key_range function does not retain the locks it acquires for the -life of the transaction, so estimates may not be repeatable. -
The flags parameter is currently unused, and must be set to 0. -
The DB->key_range function returns a non-zero error value on failure and 0 on success. -
The DB->key_range function may fail and return a non-zero error for the following conditions: -
The underlying database was not of type Btree. -
The DB->key_range function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->key_range function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_lsn.html b/bdb/docs/api_c/db_lsn.html deleted file mode 100644 index 1fc62e5e688..00000000000 --- a/bdb/docs/api_c/db_lsn.html +++ /dev/null @@ -1,36 +0,0 @@ - - - - -
-
-DB_LSN- |
-
-
- |
-#include <db.h> -
A DB_LSN is a log sequence number, which indicates a -unique position in the log. The DB_LSN structure is completely -opaque, and no application should ever need to look inside. -DB_LSN structures are used by the logging and memory pool -subsystems. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_open.html b/bdb/docs/api_c/db_open.html deleted file mode 100644 index afd410223a6..00000000000 --- a/bdb/docs/api_c/db_open.html +++ /dev/null @@ -1,182 +0,0 @@ - - - - -
-
-DB->open- |
-
-
- |
-#include <db.h> --int -DB->open(DB *db, const char *file, - const char *database, DBTYPE type, u_int32_t flags, int mode); -
The currently supported Berkeley DB file formats (or access methods) -are Btree, Hash, Queue and Recno. The Btree format is a representation -of a sorted, balanced tree structure. The Hash format is an extensible, -dynamic hashing scheme. The Queue format supports fast access to -fixed-length records accessed by sequentially or logical record number. -The Recno format supports fixed- or variable-length records, accessed -sequentially or by logical record number, and optionally retrieved from -a flat text file. -
Storage and retrieval for the Berkeley DB access methods are based on key/data -pairs, see DBT for more information. -
The DB->open interface opens the database represented by the -file and database arguments for both reading and writing. -The file argument is used as the name of a physical file on disk -that will be used to back the database. The database argument is -optional and allows applications to have multiple logical databases in a -single physical file. While no database argument needs to be -specified, it is an error to attempt to open a second database in a -file that was not initially created using a database name. -In-memory databases never intended to be preserved on disk may -be created by setting both the file and database arguments -to NULL. Note that in-memory databases can only ever be shared by -sharing the single database handle that created them, in circumstances -where doing so is safe. -
The type argument is of type DBTYPE -and must be set to one of DB_BTREE, DB_HASH, -DB_QUEUE, DB_RECNO or DB_UNKNOWN, except -that databases of type DB_QUEUE are restricted to one per -file. If type is DB_UNKNOWN, the database must -already exist and DB->open will automatically determine its type. -The DB->get_type function may be used to determine the underlying type of -databases opened using DB_UNKNOWN. -
The flags and mode arguments specify how files will be opened -and/or created if they do not already exist. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_EXCL flag is only meaningful when specified with the -DB_CREATE flag. -
The DB_TRUNCATE flag cannot be transaction protected, and it is -an error to specify it in a transaction protected environment. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by the access methods -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
Calling DB->open is a reasonably expensive operation, and -maintaining a set of open databases will normally be preferable to -repeatedly open and closing the database for each new query. -
The DB->open function returns a non-zero error value on failure and 0 on success. -
The DB->open function may fail and return a non-zero error for the following conditions: -
-The DB_THREAD flag was specified and spinlocks are not -implemented for this architecture. -
The DB_THREAD flag was specified to DB->open, but was not -specified to the DBENV->open call for the environment in which the -DB handle was created. -
A re_source file was specified with either the DB_THREAD -flag or the provided database environment supports transaction -processing. -
The DB->open function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->open function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_put.html b/bdb/docs/api_c/db_put.html deleted file mode 100644 index 85c63b7cc7e..00000000000 --- a/bdb/docs/api_c/db_put.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - -
-
-DB->put- |
-
-
- |
-#include <db.h> --int -DB->put(DB *db, - DB_TXN *txnid, DBT *key, DBT *data, u_int32_t flags); -
The DB->put function stores key/data pairs in the database. The default -behavior of the DB->put function is to enter the new key/data -pair, replacing any previously existing key if duplicates are disallowed, -or adding a duplicate data item if duplicates are allowed. If the database -supports duplicates, the DB->put function adds the new data value at the -end of the duplicate set. If the database supports sorted duplicates, -the new data value is inserted at the correct sorted location. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -txn_begin, otherwise, NULL. -
The flags parameter must be set to 0 or one of the following -values: -
There is a minor behavioral difference between the Recno and Queue access -methods for the DB_APPEND flag. If a transaction enclosing a -DB->put operation with the DB_APPEND flag aborts, the -record number may be decremented (and later re-allocated by a subsequent -DB_APPEND operation) by the Recno access method, but will not be -decremented or re-allocated by the Queue access method. -
The DB_NODUPDATA flag may not be specified to the Queue or Recno -access methods. -
Otherwise, the DB->put function returns a non-zero error value on failure and 0 on success. -
The DB->put function may fail and return a non-zero error for the following conditions: -
A record number of 0 was specified. -
An attempt was made to add a record to a fixed-length database that was too -large to fit. -
An attempt was made to do a partial put. -
The DB->put function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->put function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_remove.html b/bdb/docs/api_c/db_remove.html deleted file mode 100644 index e8dae864538..00000000000 --- a/bdb/docs/api_c/db_remove.html +++ /dev/null @@ -1,108 +0,0 @@ - - - - -
-
-DB->remove- |
-
-
- |
-#include <db.h> --int -DB->remove(DB *db, - const char *file, const char *database, u_int32_t flags); -
The DB->remove interface removes the database specified by the -file and database arguments. If no database is -specified, the physical file represented by file is removed, -incidentally removing all databases that it contained. -
If a physical file is being removed and logging is currently enabled in -the database environment, no database in the file may be open when the -DB->remove function is called. Otherwise, no reference count of database -use is maintained by Berkeley DB. Applications should not remove databases that -are currently in use. In particular, some architectures do not permit -the removal of files with open handles. On these architectures, attempts -to remove databases that are currently in use will fail. -
The flags parameter is currently unused, and must be set to 0. -
Once DB->remove has been called, regardless of its return, the -DB handle may not be accessed again. -
The DB->remove function returns a non-zero error value on failure and 0 on success. -
The DB->remove function may fail and return a non-zero error for the following conditions: -
The DB->remove function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->remove function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_rename.html b/bdb/docs/api_c/db_rename.html deleted file mode 100644 index ff90836c6b2..00000000000 --- a/bdb/docs/api_c/db_rename.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - -
-
-DB->rename- |
-
-
- |
-#include <db.h> --int -DB->rename(DB *db, const char *file, - const char *database, const char *newname, u_int32_t flags); -
The DB->rename interface renames the database specified by the -file and database arguments to newname. If no -database is specified, the physical file represented by -file is renamed, incidentally renaming all databases that it -contained. -
If a physical file is being renamed and logging is currently enabled in -the database environment, no database in the file may be open when the -DB->rename function is called. Otherwise, no reference count of database -use is maintained by Berkeley DB. Applications should not rename databases that -are currently in use. In particular, some architectures do not permit -renaming files with open handles. On these architectures, attempts to -rename databases that are currently in use will fail. -
The flags parameter is currently unused, and must be set to 0. -
Once DB->rename has been called, regardless of its return, the -DB handle may not be accessed again. -
The DB->rename function returns a non-zero error value on failure and 0 on success. -
The DB->rename function may fail and return a non-zero error for the following conditions: -
The DB->rename function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->rename function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_append_recno.html b/bdb/docs/api_c/db_set_append_recno.html deleted file mode 100644 index 4b90190ffbd..00000000000 --- a/bdb/docs/api_c/db_set_append_recno.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-DB->set_append_recno- |
-
-
- |
-#include <db.h> --int -DB->set_append_recno(DB *, - int (*db_append_recno_fcn)(DB *dbp, DBT *data, db_recno_t recno)); -
When using the DB_APPEND option of the DB->put method, -it may be useful to modify the stored data based on the generated key. -If a callback function is specified using the -DB->set_append_recno function, it will be called after the record number -has been selected but before the data has been stored. -The callback function must return 0 on success and errno or -a value outside of the Berkeley DB error name space on failure. -
The called function must take three arguments: a reference to the -enclosing database handle, the data DBT to be stored and the -selected record number. The called function may then modify the data -DBT. -
The DB->set_append_recno interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_append_recno function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_bt_compare.html b/bdb/docs/api_c/db_set_bt_compare.html deleted file mode 100644 index bf38ee51d94..00000000000 --- a/bdb/docs/api_c/db_set_bt_compare.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - -
-
-DB->set_bt_compare- |
-
-
- |
-#include <db.h> --int -DB->set_bt_compare(DB *db, - int (*bt_compare_fcn)(DB *, const DBT *, const DBT *)); -
Set the Btree key comparison function. The comparison function is -called when it is necessary to compare a key specified by the -application with a key currently stored in the tree. The first argument -to the comparison function is the DBT representing the -application supplied key, the second is the current tree's key. -
The comparison function must return an integer value less than, equal -to, or greater than zero if the first key argument is considered to be -respectively less than, equal to, or greater than the second key -argument. In addition, the comparison function must cause the keys in -the database to be well-ordered. The comparison function -must correctly handle any key values used by the application (possibly -including zero-length keys). In addition, when Btree key prefix -comparison is being performed (see DB->set_bt_prefix for more -information), the comparison routine may be passed a prefix of any -database key. The data and size fields of the -DBT are the only fields that may be used for the purposes of -this comparison. -
If no comparison function is specified, the keys are compared lexically, -with shorter keys collating before longer keys. The same comparison -method must be used each time a particular Btree is opened. -
The DB->set_bt_compare interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_bt_compare function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_bt_minkey.html b/bdb/docs/api_c/db_set_bt_minkey.html deleted file mode 100644 index c36f3637ba5..00000000000 --- a/bdb/docs/api_c/db_set_bt_minkey.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-DB->set_bt_minkey- |
-
-
- |
-#include <db.h> --int -DB->set_bt_minkey(DB *db, u_int32_t bt_minkey); -
Set the minimum number of keys that will be stored on any single -Btree page. -
This value is used to determine which keys will be stored on overflow -pages, i.e. if a key or data item is larger than the underlying database -page size divided by the bt_minkey value, it will be stored on -overflow pages instead of within the page itself. The bt_minkey -value specified must be at least 2; if bt_minkey is not explicitly -set, a value of 2 is used. -
The DB->set_bt_minkey interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_bt_minkey function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_bt_prefix.html b/bdb/docs/api_c/db_set_bt_prefix.html deleted file mode 100644 index 88bf3157f97..00000000000 --- a/bdb/docs/api_c/db_set_bt_prefix.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - -
-
-DB->set_bt_prefix- |
-
-
- |
-#include <db.h> --int -DB->set_bt_prefix(DB *db, - size_t (*bt_prefix_fcn)(DB *, const DBT *, const DBT *)); -
Set the Btree prefix function. The prefix function must return the -number of bytes of the second key argument that would be required by -the Btree key comparison function to determine the second key argument's -ordering relationship with respect to the first key argument. If the -two keys are equal, the key length should be returned. The prefix -function must correctly handle any key values used by the application -(possibly including zero-length keys). The data and -size fields of the DBT are the only fields that may be -used for the purposes of this determination. -
The prefix function is used to determine the amount by which keys stored -on the Btree internal pages can be safely truncated without losing their -uniqueness. See the Btree -prefix comparison section of the Reference Guide for more details about -how this works. The usefulness of this is data dependent, but in some -data sets can produce significantly reduced tree sizes and search times. -
If no prefix function or key comparison function is specified by the -application, a default lexical comparison function is used as the prefix -function. If no prefix function is specified and a key comparison -function is specified, no prefix function is used. It is an error to -specify a prefix function without also specifying a key comparison -function. -
The DB->set_bt_prefix interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_bt_prefix function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_cachesize.html b/bdb/docs/api_c/db_set_cachesize.html deleted file mode 100644 index fd7176cbf7d..00000000000 --- a/bdb/docs/api_c/db_set_cachesize.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - -
-
-DB->set_cachesize- |
-
-
- |
-#include <db.h> --int -DB->set_cachesize(DB *db, - u_int32_t gbytes, u_int32_t bytes, int ncache); -
Set the size of the database's shared memory buffer pool, i.e., the cache, -to gbytes gigabytes plus bytes. The cache should be the -size of the normal working data set of the application, with some small -amount of additional memory for unusual situations. (Note, the working -set is not the same as the number of simultaneously referenced pages, and -should be quite a bit larger!) -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
As databases opened within Berkeley DB environments use the cache specified to -the environment, it is an error to attempt to set a cache in a database -created within an environment. -
The DB->set_cachesize interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_cachesize function returns a non-zero error value on failure and 0 on success. -
The specified cache size was impossibly small. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_dup_compare.html b/bdb/docs/api_c/db_set_dup_compare.html deleted file mode 100644 index 2ac6ed9dec2..00000000000 --- a/bdb/docs/api_c/db_set_dup_compare.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - -
-
-DB->set_dup_compare- |
-
-
- |
-#include <db.h> --int -DB->set_dup_compare(DB *db, - int (*dup_compare_fcn)(DB *, const DBT *, const DBT *)); -
Set the duplicate data item comparison function. The comparison function -is called when it is necessary to compare a data item specified by the -application with a data item currently stored in the tree. The first -argument to the comparison function is the DBT representing the -application's data item, the second is the current tree's data item. -
The comparison function must return an integer value less than, equal -to, or greater than zero if the first data item argument is considered -to be respectively less than, equal to, or greater than the second data -item argument. In addition, the comparison function must cause the data -items in the set to be well-ordered. The comparison function -must correctly handle any data item values used by the application -(possibly including zero-length data items). The data and -size fields of the DBT are the only fields that may be -used for the purposes of this comparison. -
If no comparison function is specified, the data items are compared -lexically, with shorter data items collating before longer data items. -The same duplicate data item comparison method must be used each time -a particular Btree is opened. -
The DB->set_dup_compare interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_dup_compare function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_errcall.html b/bdb/docs/api_c/db_set_errcall.html deleted file mode 100644 index 97d8d9a3aca..00000000000 --- a/bdb/docs/api_c/db_set_errcall.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - -
-
-DB->set_errcall- |
-
-
- |
-#include <db.h> --void -DB->set_errcall(DB *, - void (*db_errcall_fcn)(const char *errpfx, char *msg)); -
The DB->set_errcall function is used to enhance the mechanism for reporting error -messages to the application. In some cases, when an error occurs, Berkeley DB -will call db_errcall_fcn with additional error information. The -function must be declared with two arguments; the first will be the prefix -string (as previously set by DB->set_errpfx or -DBENV->set_errpfx), the second will be the error message string. -It is up to the db_errcall_fcn function to display the error -message in an appropriate manner. -
Alternatively, you can use the DB->set_errfile or -DBENV->set_errfile functions to display the additional information -via a C library FILE *. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
For DB handles opened inside of Berkeley DB environments, calling the -DB->set_errcall function affects the entire environment and is equivalent to calling -the DBENV->set_errcall function. -
The DB->set_errcall interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_errfile.html b/bdb/docs/api_c/db_set_errfile.html deleted file mode 100644 index 5d160ed5cf2..00000000000 --- a/bdb/docs/api_c/db_set_errfile.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - -
-
-DB->set_errfile- |
-
-
- |
-#include <db.h> --void -DB->set_errfile(DB *db, FILE *errfile); -
The DB->set_errfile function is used to enhance the mechanism for reporting error -messages to the application by setting a C library FILE * to be used for -displaying additional Berkeley DB error messages. In some cases, when an error -occurs, Berkeley DB will output an additional error message to the specified -file reference. -
The error message will consist of the prefix string and a colon -(":") (if a prefix string was previously specified using -DB->set_errpfx or DBENV->set_errpfx), an error string, and -a trailing <newline> character. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
For DB handles opened inside of Berkeley DB environments, calling the -DB->set_errfile function affects the entire environment and is equivalent to calling -the DBENV->set_errfile function. -
The DB->set_errfile interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_errpfx.html b/bdb/docs/api_c/db_set_errpfx.html deleted file mode 100644 index baf8f61fef7..00000000000 --- a/bdb/docs/api_c/db_set_errpfx.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
-DB->set_errpfx- |
-
-
- |
-#include <db.h> --void -DB->set_errpfx(DB *db, const char *errpfx); -
Set the prefix string that appears before error messages issued by Berkeley DB. -
The DB->set_errpfx function does not copy the memory referenced by the -errpfx argument, rather, it maintains a reference to it. This -allows applications to modify the error message prefix at any time, -without repeatedly calling DB->set_errpfx, but means that the -memory must be maintained until the handle is closed. -
For DB handles opened inside of Berkeley DB environments, calling the -DB->set_errpfx function affects the entire environment and is equivalent to calling -the DBENV->set_errpfx function. -
The DB->set_errpfx interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_feedback.html b/bdb/docs/api_c/db_set_feedback.html deleted file mode 100644 index 213060ee765..00000000000 --- a/bdb/docs/api_c/db_set_feedback.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - -
-
-DB->set_feedback- |
-
-
- |
-#include <db.h> --int -DB->set_feedback(DB *, - void (*db_feedback_fcn)(DB *dbp, int opcode, int pct)); -
Some operations performed by the Berkeley DB library can take non-trivial -amounts of time. The DB->set_feedback function can be used by -applications to monitor progress within these operations. -
When an operation is likely to take a long time, Berkeley DB will call the -specified callback function. This function must be declared with -three arguments: the first will be a reference to the enclosing database -handle, the second a flag value, and the third the percent of the -operation that has been completed, specified as an integer value between -0 and 100. It is up to the callback function to display this -information in an appropriate manner. -
The opcode argument may take on any of the following values: -
The DB->set_feedback interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DB->set_feedback function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_flags.html b/bdb/docs/api_c/db_set_flags.html deleted file mode 100644 index f1823381776..00000000000 --- a/bdb/docs/api_c/db_set_flags.html +++ /dev/null @@ -1,181 +0,0 @@ - - - - -
-
-DB->set_flags- |
-
-
- |
-#include <db.h> --int -DB->set_flags(DB *db, u_int32_t flags); -
Calling DB->set_flags is additive, there is no way to clear flags. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The following flags may be specified for the Btree access method: -
Logical record numbers in Btree databases are mutable in the face of -record insertion or deletion. See the DB_RENUMBER flag in the Recno -access method information for further discussion. -
Maintaining record counts within a Btree introduces a serious point of -contention, namely the page locations where the record counts are stored. -In addition, the entire tree must be locked during both insertions and -deletions, effectively single-threading the tree for those operations. -Specifying DB_RECNUM can result in serious performance degradation for -some applications and data sets. -
It is an error to specify both DB_DUP and DB_RECNUM. -
The following flags may be specified for the Hash access method: -
There are no additional flags that may be specified for the Queue access -method. -
The following flags may be specified for the Recno access method: -
Using the DB->put or DBcursor->c_put interfaces to create new -records will cause the creation of multiple records if the record number -is more than one greater than the largest record currently in the -database. For example, creating record 28, when record 25 was previously -the last record in the database, will create records 26 and 27 as well as -28. Attempts to retrieve records that were created in this manner will -result in an error return of DB_KEYEMPTY. -
If a created record is not at the end of the database, all records -following the new record will be automatically renumbered upward by 1. -For example, the creation of a new record numbered 8 causes records -numbered 8 and greater to be renumbered upward by 1. If a cursor was -positioned to record number 8 or greater before the insertion, it will be -shifted upward 1 logical record, continuing to reference the same record -as it did before. -
For these reasons, concurrent access to a Recno database with the -DB_RENUMBER flag specified may be largely meaningless, although -it is supported. -
The DB->set_flags interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_flags function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_h_ffactor.html b/bdb/docs/api_c/db_set_h_ffactor.html deleted file mode 100644 index c3bbb607ea5..00000000000 --- a/bdb/docs/api_c/db_set_h_ffactor.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - -
-
-DB->set_h_ffactor- |
-
-
- |
-#include <db.h> --int -DB->set_h_ffactor(DB *db, u_int32_t h_ffactor); -
Set the desired density within the hash table. -
The density is an approximation of the number of keys allowed to -accumulate in any one bucket, determining when the hash table grows or -shrinks. If you know the average sizes of the keys and data in your -dataset, setting the fill factor can enhance performance. A reasonable -rule computing fill factor is to set it to: -
-(pagesize - 32) / (average_key_size + average_data_size + 8)
If no value is specified, the fill factor will be selected dynamically as -pages are filled. -
The DB->set_h_ffactor interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_h_ffactor function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_h_hash.html b/bdb/docs/api_c/db_set_h_hash.html deleted file mode 100644 index cae03fa72b3..00000000000 --- a/bdb/docs/api_c/db_set_h_hash.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - -
-
-DB->set_h_hash- |
-
-
- |
-#include <db.h> --int -DB->set_h_hash(DB *db, - u_int32_t (*h_hash_fcn)(DB *, const void *bytes, u_int32_t length)); -
Set a user defined hash method; if no hash method is specified, a default -hash method is used. Since no hash method performs equally well on all -possible data, the user may find that the built-in hash method performs -poorly with a particular data set. User specified hash functions must -take a pointer to a byte string and a length as arguments and return a -value of type -u_int32_t. -The hash function must handle any key values used by the application -(possibly including zero-length keys). -
If a hash method is specified, DB->open will attempt to determine -if the hash method specified is the same as the one with which the database -was created, and will fail if it detects that it is not. -
The DB->set_h_hash interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_h_hash function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_h_nelem.html b/bdb/docs/api_c/db_set_h_nelem.html deleted file mode 100644 index d052afff7dc..00000000000 --- a/bdb/docs/api_c/db_set_h_nelem.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - -
-
-DB->set_h_nelem- |
-
-
- |
-#include <db.h> --int -DB->set_h_nelem(DB *db, u_int32_t h_nelem); -
Set an estimate of the final size of the hash table. -
If not set or set too low, hash tables will still expand gracefully -as keys are entered, although a slight performance degradation may be -noticed. -
The DB->set_h_nelem interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_h_nelem function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_lorder.html b/bdb/docs/api_c/db_set_lorder.html deleted file mode 100644 index a9a3c923037..00000000000 --- a/bdb/docs/api_c/db_set_lorder.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-DB->set_lorder- |
-
-
- |
-#include <db.h> --int -DB->set_lorder(DB *db, int lorder); -
Set the byte order for integers in the stored database metadata. The -number should represent the order as an integer, for example, big endian -order is the number 4,321, and little endian order is the number 1,234. -If lorder is not explicitly set, the host order of the machine -where the Berkeley DB library was compiled is used. -
The value of lorder is ignored except when databases are being -created. If a database already exists, the byte order it uses is -determined when the database is opened. -
The access methods provide no guarantees about the byte ordering of the -application data stored in the database, and applications are responsible -for maintaining any necessary ordering. -
The DB->set_lorder interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_lorder function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_malloc.html b/bdb/docs/api_c/db_set_malloc.html deleted file mode 100644 index 2d13196a3ad..00000000000 --- a/bdb/docs/api_c/db_set_malloc.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - -
-
-DB->set_malloc- |
-
-
- |
-#include <db.h> --int -DB->set_malloc(DB *db, void *(*db_malloc)(size_t size)); -
Set the allocation function used by the DB methods to allocate -memory in which to return key/data items to the application. -
The DB_DBT_MALLOC flag, when specified in the DBT object, -will cause the DB methods to allocate and re-allocate memory which -then becomes the responsibility of the calling application. See DBT -for more information. -
On systems where there may be multiple library versions of malloc (notably -Windows NT), specifying the DB_DBT_MALLOC flag will fail because -the DB library will allocate memory from a different heap than -the application will use to free it. To avoid this problem, the -DB->set_malloc function can be used to pass Berkeley DB a reference to the -application's allocation routine, in which case it will be used to -allocate the memory returned when the DB_DBT_MALLOC flag is set. -
The function specified must match the calling conventions of the -ANSI C X3.159-1989 (ANSI C) library routine of the same name. -
The DB->set_malloc interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_malloc function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_pagesize.html b/bdb/docs/api_c/db_set_pagesize.html deleted file mode 100644 index 7fa4af53dbc..00000000000 --- a/bdb/docs/api_c/db_set_pagesize.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-DB->set_pagesize- |
-
-
- |
-#include <db.h> --int -DB->set_pagesize(DB *db, u_int32_t pagesize); -
Set the size of the pages used to hold items in the database, in bytes. -The minimum page size is 512 bytes and the maximum page size is 64K bytes. -If the page size is not explicitly set, one is selected based on the -underlying filesystem I/O block size. The automatically selected size -has a lower limit of 512 bytes and an upper limit of 16K bytes. -
For information on tuning the Berkeley DB page size, see -Selecting a page size. -
The DB->set_pagesize interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_pagesize function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_paniccall.html b/bdb/docs/api_c/db_set_paniccall.html deleted file mode 100644 index 506272c9630..00000000000 --- a/bdb/docs/api_c/db_set_paniccall.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - -
-
-DB->set_paniccall- |
-
-
- |
-#include <db.h> --int -DB->set_paniccall(DB *db, - void (*paniccall)(DB_ENV *, int errval)); -
Errors can occur in the Berkeley DB library where the only solution is to shut -down the application and run recovery. (For example, if Berkeley DB is unable -to write log records to disk because there is insufficient disk space.) -In these cases, the value DB_RUNRECOVERY is returned by Berkeley DB. -
In these cases, it is also often simpler to shut down the application when -such errors occur rather than attempting to gracefully return up the stack. -The DB->set_paniccall function is used to specify a function to be called when -DB_RUNRECOVERY is about to be returned from a Berkeley DB method. When -called, the dbenv argument will be a reference to the current -environment, and the errval argument is the error value that would -have been returned to the calling function. -
For DB handles opened inside of Berkeley DB environments, calling the -DB->set_paniccall function affects the entire environment and is equivalent to calling -the DBENV->set_paniccall function. -
The DB->set_paniccall interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DB->set_paniccall function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_q_extentsize.html b/bdb/docs/api_c/db_set_q_extentsize.html deleted file mode 100644 index 7ab89bdba5d..00000000000 --- a/bdb/docs/api_c/db_set_q_extentsize.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-DB->set_q_extentsize- |
-
-
- |
-#include <db.h> --int -DB->set_q_extentsize(DB *db, u_int32_t extentsize); -
Set the size of the extents used to hold pages in a Queue database, -specified as a number of pages. Each extent is created as a separate -physical file. If no extent size is set, the default behavior is to -create only a single underlying database file. -
For information on tuning the extent size, see -Selecting a extent size. -
The DB->set_q_extentsize interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_q_extentsize function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_re_delim.html b/bdb/docs/api_c/db_set_re_delim.html deleted file mode 100644 index 6101130a5e5..00000000000 --- a/bdb/docs/api_c/db_set_re_delim.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-DB->set_re_delim- |
-
-
- |
-#include <db.h> --int -DB->set_re_delim(DB *db, int re_delim); -
Set the delimiting byte used to mark the end of a record in the backing -source file for the Recno access method. -
This byte is used for variable length records, if the re_source -file is specified. If the re_source file is specified and no -delimiting byte was specified, <newline> characters (i.e. -ASCII 0x0a) are interpreted as end-of-record markers. -
The DB->set_re_delim interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_re_delim function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_re_len.html b/bdb/docs/api_c/db_set_re_len.html deleted file mode 100644 index 67b67ddfc0a..00000000000 --- a/bdb/docs/api_c/db_set_re_len.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-DB->set_re_len- |
-
-
- |
-#include <db.h> --int -DB->set_re_len(DB *db, u_int32_t re_len); -
For the Queue access method, specify that the records are of length -re_len. -
For the Recno access method, specify that the records are fixed-length, -not byte delimited, and are of length re_len. -
Any records added to the database that are less than re_len bytes -long are automatically padded (see DB->set_re_pad for more -information). -
Any attempt to insert records into the database that are greater than -re_len bytes long will cause the call to fail immediately and -return an error. -
The DB->set_re_len interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_re_len function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_re_pad.html b/bdb/docs/api_c/db_set_re_pad.html deleted file mode 100644 index 43a6f947f5d..00000000000 --- a/bdb/docs/api_c/db_set_re_pad.html +++ /dev/null @@ -1,88 +0,0 @@ - - - - -
-
-DB->set_re_pad- |
-
-
- |
-#include <db.h> --int -DB->set_re_pad(DB *db, int re_pad); -
Set the padding character for short, fixed-length records for the Queue -and Recno access methods. -
If no pad character is specified, <space> characters (i.e., -ASCII 0x20) are used for padding. -
The DB->set_re_pad interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_re_pad function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_re_source.html b/bdb/docs/api_c/db_set_re_source.html deleted file mode 100644 index 1a57cfea339..00000000000 --- a/bdb/docs/api_c/db_set_re_source.html +++ /dev/null @@ -1,130 +0,0 @@ - - - - -
-
-DB->set_re_source- |
-
-
- |
-#include <db.h> --int -DB->set_re_source(DB *db, char *re_source); -
Set the underlying source file for the Recno access method. The purpose -of the re_source value is to provide fast access and modification -to databases that are normally stored as flat text files. -
If the re_source field is set, it specifies an underlying flat -text database file that is read to initialize a transient record number -index. In the case of variable length records, the records are separated -as specified by DB->set_re_delim. For example, standard UNIX -byte stream files can be interpreted as a sequence of variable length -records separated by <newline> characters. -
In addition, when cached data would normally be written back to the -underlying database file (e.g., the DB->close or DB->sync -methods are called), the in-memory copy of the database will be written -back to the re_source file. -
By default, the backing source file is read lazily, i.e., records are not -read from the file until they are requested by the application. -If multiple processes (not threads) are accessing a Recno database -concurrently and either inserting or deleting records, the backing source -file must be read in its entirety before more than a single process -accesses the database, and only that process should specify the backing -source file as part of the DB->open call. See the DB_SNAPSHOT -flag for more information. -
Reading and writing the backing source file specified by re_source -cannot be transactionally protected because it involves filesystem -operations that are not part of the Db transaction methodology. -For this reason, if a temporary database is used to hold the records, -i.e., a NULL was specified as the file argument to DB->open, -it is possible to lose the contents of the re_source file, e.g., -if the system crashes at the right instant. -If a file is used to hold the database, i.e., a file name was specified -as the file argument to DB->open, normal database -recovery on that file can be used to prevent information loss, -although it is still possible that the contents of re_source -will be lost if the system crashes. -
The re_source file must already exist (but may be zero-length) when -DB->open is called. -
It is not an error to specify a read-only re_source file when -creating a database, nor is it an error to modify the resulting database. -However, any attempt to write the changes to the backing source file using -either the DB->sync or DB->close functions will fail, of course. -Specify the DB_NOSYNC flag to the DB->close function to stop it -from attempting to write the changes to the backing file, instead, they -will be silently discarded. -
For all of the above reasons, the re_source field is generally -used to specify databases that are read-only for DB applications, -and that are either generated on the fly by software tools, or modified -using a different mechanism, e.g., a text editor. -
The DB->set_re_source interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_re_source function returns a non-zero error value on failure and 0 on success. -
Called after DB->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_set_realloc.html b/bdb/docs/api_c/db_set_realloc.html deleted file mode 100644 index b3d8a05f771..00000000000 --- a/bdb/docs/api_c/db_set_realloc.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - -
-
-DB->set_realloc- |
-
-
- |
-#include <db.h> --int -DB->set_realloc(DB *db, - void *(*db_realloc_fcn)(void *ptr, size_t size)); -
Set the realloc function used by the DB methods to allocate memory -in which to return key/data items to the application. -
The DB_DBT_REALLOC flag, when specified in the DBT object, -will cause the DB methods to allocate and re-allocate memory which -then becomes the responsibility of the calling application. See DBT -for more information. -
On systems where there may be multiple library versions of realloc (notably -Windows NT), specifying the DB_DBT_REALLOC flag will fail because -the DB library will allocate memory from a different heap than -the application will use to free it. To avoid this problem, the -DB->set_realloc function can be used to pass Berkeley DB a reference to the -application's allocation routine, in which case it will be used to -allocate the memory returned when the DB_DBT_REALLOC flag is set. -
The function specified must match the calling conventions of the -ANSI C X3.159-1989 (ANSI C) library routine of the same name. -
The DB->set_realloc interface may only be used to configure Berkeley DB before -the DB->open interface is called. -
The DB->set_realloc function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_stat.html b/bdb/docs/api_c/db_stat.html deleted file mode 100644 index 92412d76d78..00000000000 --- a/bdb/docs/api_c/db_stat.html +++ /dev/null @@ -1,195 +0,0 @@ - - - - -
-
-DB->stat- |
-
-
- |
-#include <db.h> --int -DB->stat(DB *db, - void *sp, void *(*db_malloc)(size_t), u_int32_t flags); -
The DB->stat function creates a statistical structure and -copies a pointer to it into user-specified memory locations. -Specifically, if sp is non-NULL, a pointer to the statistics -for the database are copied into the memory location it references. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The flags parameter must be set to 0 or the following value: -
This option is only available for Recno databases, or Btree databases -where the underlying database was created with the DB_RECNUM -flag. -
The DB->stat function may access all of the pages in the database, -incurring a severe performance penalty as well as possibly flushing the -underlying buffer pool. -
In the presence of multiple threads or processes accessing an active -database, the information returned by DB->stat may be out-of-date. -
If the database was not opened readonly and the DB_CACHED_COUNTS -flag was not specified, the cached key and record numbers will be updated -after the statistical information has been gathered. -
The DB->stat function cannot be transaction protected. For this reason, -it should be called in a thread of control that has no open cursors or -active transactions. -
The DB->stat function returns a non-zero error value on failure and 0 on success. -
In the case of a Hash database, -the statistics are stored in a structure of type DB_HASH_STAT. The -following fields will be filled in: -
In the case of a Btree or Recno database, -the statistics are stored in a structure of type DB_BTREE_STAT. The -following fields will be filled in: -
For the Recno Access Method, the number of records in the database. -
For the Recno Access Method, the number of records in the database. If -the database has been configured to not re-number records during -deletion, the number of records will only reflect undeleted records. -
In the case of a Queue database, -the statistics are stored in a structure of type DB_QUEUE_STAT. The -following fields will be filled in: -
The DB->stat function returns a non-zero error value on failure and 0 on success. -
The DB->stat function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->stat function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_sync.html b/bdb/docs/api_c/db_sync.html deleted file mode 100644 index 6af624a88f3..00000000000 --- a/bdb/docs/api_c/db_sync.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - -
-
-DB->sync- |
-
-
- |
-#include <db.h> --int -DB->sync(DB *db, u_int32_t flags); -
The DB->sync function flushes any cached information to disk. -
If the database is in memory only, the DB->sync function has no effect and -will always succeed. -
The flags parameter is currently unused, and must be set to 0. -
See DB->close for a discussion of Berkeley DB and cached data. -
The DB->sync function returns a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if the underlying database still has -dirty pages in the cache. (The only reason to return -DB_INCOMPLETE is if another thread of control was writing pages -in the underlying database file at the same time as the -DB->sync function was being called. For this reason, a return of -DB_INCOMPLETE can normally be ignored, or, in cases where it is -a possible return value, there may be no reason to call -DB->sync.) -
The DB->sync function may fail and return a non-zero error for the following conditions: -
The DB->sync function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->sync function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_upgrade.html b/bdb/docs/api_c/db_upgrade.html deleted file mode 100644 index e31b4d447af..00000000000 --- a/bdb/docs/api_c/db_upgrade.html +++ /dev/null @@ -1,135 +0,0 @@ - - - - -
-
-DB->upgrade- |
-
-
- |
-#include <db.h> --int -DB->upgrade(DB *db, const char *file, u_int32_t flags); -
The DB->upgrade function upgrades all of the databases included in the -file file, if necessary. If no upgrade is necessary, -DB->upgrade always returns success. -
Database upgrades are done in place and are destructive, e.g., if pages -need to be allocated and no disk space is available, the database may be -left corrupted. Backups should be made before databases are upgraded. -See Upgrading databases for more -information. -
Unlike all other database operations, DB->upgrade may only be done -on a system with the same byte-order as the database. -
The flags parameter must be set to 0 or one of the following -values: -
As part of the upgrade from the Berkeley DB 3.0 release to the 3.1 release, the -on-disk format of duplicate data items changed. To correctly upgrade the -format requires applications specify if duplicate data items in the -database are sorted or not. Specifying the DB_DUPSORT flag -informs DB->upgrade that the duplicates are sorted, otherwise they -are assumed to be unsorted. Incorrectly specifying the value of this flag -may lead to database corruption. -
Further, because the DB->upgrade function upgrades a physical file -(including all of the databases it contains), it is not possible to use -DB->upgrade to upgrade files where some of the databases it -includes have sorted duplicate data items and some of the databases it -includes have unsorted duplicate data items. If the file does not have -more than a single database, or the databases do not support duplicate -data items, or all of the databases that support duplicate data items -support the same style of duplicates (either sorted or unsorted), -DB->upgrade will work correctly as long as the DB_DUPSORT -flag is correctly specified. Otherwise, the file cannot be upgraded using -DB->upgrade, and must be upgraded manually by dumping and -re-loading the databases. -
The DB->upgrade function returns a non-zero error value on failure and 0 on success. -
The DB->upgrade function is the underlying function used by the db_upgrade utility. -See the db_upgrade utility source code for an example of using DB->upgrade -in a IEEE/ANSI Std 1003.1 (POSIX) environment. -
The DB->upgrade function may fail and return a non-zero error for the following conditions: -
The database is not in the same byte-order as the system. -
The DB->upgrade function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->upgrade function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/db_verify.html b/bdb/docs/api_c/db_verify.html deleted file mode 100644 index d011d90ab8d..00000000000 --- a/bdb/docs/api_c/db_verify.html +++ /dev/null @@ -1,150 +0,0 @@ - - - - -
-
-DB->verify- |
-
-
- |
-#include <db.h> --int -DB->verify(DB *db, const char *file, - const char *database, FILE *outfile, u_int32_t flags); -
The DB->verify function verifies the integrity of all databases in the -file specified by the file argument, and optionally outputs the databases' -key/data pairs to a file stream. -
The flags parameter must be set to 0 or one of the following -values: -
Because the key/data pairs are output in page order as opposed to the sort -order used by db_dump, using DB->verify to dump key/data -pairs normally produces less than optimal loads for Btree databases. -
In addition, the following flags may be set by bitwise inclusively OR'ing them into the -flags parameter: -
The DB->verify function normally verifies that btree keys and duplicate -items are correctly sorted and hash keys are correctly hashed. If the -file being verified contains multiple databases using differing sorting -or hashing algorithms, some of them must necessarily fail database -verification as only one sort order or hash function can be specified -before DB->verify is called. To verify files with multiple -databases having differing sorting orders or hashing functions, first -perform verification of the file as a whole by using the -DB_NOORDERCHK flag, and then individually verify the sort order -and hashing function for each database in the file using the -DB_ORDERCHKONLY flag. -
When this flag is specified, a database argument should also be -specified, indicating the database in the physical file which is to be -checked. This flag is only safe to use on databases that have already -successfully been verified using DB->verify with the -DB_NOORDERCHK flag set. -
The database argument must be set to NULL except when the -DB_ORDERCHKONLY flag is set. -
The DB->verify function returns a non-zero error value on failure, 0 on success, and DB_VERIFY_BAD if a database is corrupted. When the -DB_SALVAGE flag is specified, the DB_VERIFY_BAD return -means that all key/data pairs in the file may not have been successfully -output. -
The DB->verify function is the underlying function used by the db_verify utility. -See the db_verify utility source code for an example of using DB->verify -in a IEEE/ANSI Std 1003.1 (POSIX) environment. -
The DB->verify function may fail and return a non-zero error for the following conditions: -
The DB->verify function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DB->verify function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbc_close.html b/bdb/docs/api_c/dbc_close.html deleted file mode 100644 index 20eb28d953d..00000000000 --- a/bdb/docs/api_c/dbc_close.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - -
-
-DBcursor->c_close- |
-
-
- |
-#include <db.h> --int -DBcursor->c_close(DBC *cursor); -
The DBcursor->c_close function discards the cursor. -
It is possible for the DBcursor->c_close function to return -DB_LOCK_DEADLOCK, signaling that any enclosing transaction should -be aborted. If the application is already intending to abort the -transaction, this error should be ignored, and the application should -proceed. -
Once DBcursor->c_close has been called, regardless of its return, the -cursor handle may not be used again. -
The DBcursor->c_close function returns a non-zero error value on failure and 0 on success. -
The DBcursor->c_close function may fail and return a non-zero error for the following conditions: -
The cursor was previously closed. -
The DBcursor->c_close function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBcursor->c_close function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbc_count.html b/bdb/docs/api_c/dbc_count.html deleted file mode 100644 index 434a0ce8cbb..00000000000 --- a/bdb/docs/api_c/dbc_count.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - -
-
-DBcursor->c_count- |
-
-
- |
-#include <db.h> --int -DBC->c_count(DBC *cursor, db_recno_t *countp, u_int32_t flags); -
The DBcursor->c_count function returns a count of the number of duplicate data -items for the key referenced by the -cursor into the memory location referenced by countp. -If the underlying database does not support duplicate data items the call -will still succeed and a count of 1 will be returned. -
The flags parameter is currently unused, and must be set to 0. -
If the cursor argument is not yet initialized, the DBcursor->c_count function will return EINVAL. -
Otherwise, the DBcursor->c_count function returns a non-zero error value on failure and 0 on success. -
The DBcursor->c_count function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBcursor->c_count function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbc_del.html b/bdb/docs/api_c/dbc_del.html deleted file mode 100644 index 110d97471c8..00000000000 --- a/bdb/docs/api_c/dbc_del.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DBcursor->c_del- |
-
-
- |
-#include <db.h> --int -DBcursor->c_del(DBC *cursor, u_int32_t flags); -
The DBcursor->c_del function deletes the key/data pair currently referenced by -the cursor. -
The flags parameter is currently unused, and must be set to 0. -
The cursor position is unchanged after a delete, and subsequent calls to -cursor functions expecting the cursor to reference an existing key will -fail. -
If the element has already been deleted, DBcursor->c_del will return -DB_KEYEMPTY. -
If the cursor is not yet initialized, the DBcursor->c_del function will return EINVAL. -
Otherwise, the DBcursor->c_del function returns a non-zero error value on failure and 0 on success. -
The DBcursor->c_del function may fail and return a non-zero error for the following conditions: -
The DBcursor->c_del function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBcursor->c_del function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbc_dup.html b/bdb/docs/api_c/dbc_dup.html deleted file mode 100644 index 42e3531ca04..00000000000 --- a/bdb/docs/api_c/dbc_dup.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-DBcursor->c_dup- |
-
-
- |
-#include <db.h> --int -DBC->c_dup(DBC *cursor, DBC **cursorp, u_int32_t flags); -
The DBcursor->c_dup function creates a new cursor that uses the same transaction -and locker ID as the original cursor. This is useful when an application -is using locking and requires two or more cursors in the same thread of -control. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
When using the Berkeley DB Concurrent Data Store product, there can be only one active write cursor -at a time. For this reason, attempting to duplicate a cursor for which -the DB_WRITECURSOR flag was specified during creation will return -an error. -
If the cursor argument is not yet initialized, the DBcursor->c_dup function will return EINVAL. -
Otherwise, the DBcursor->c_dup function returns a non-zero error value on failure and 0 on success. -
The DBcursor->c_dup function may fail and return a non-zero error for the following conditions: -
The cursor argument was created using the -DB_WRITECURSOR flag in the Berkeley DB Concurrent Data Store product. -
The DBcursor->c_dup function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBcursor->c_dup function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbc_get.html b/bdb/docs/api_c/dbc_get.html deleted file mode 100644 index 014661f33e7..00000000000 --- a/bdb/docs/api_c/dbc_get.html +++ /dev/null @@ -1,167 +0,0 @@ - - - - -
-
-DBcursor->c_get- |
-
-
- |
-#include <db.h> --int -DBcursor->c_get(DBC *cursor, - DBT *key, DBT *data, u_int32_t flags); -
The DBcursor->c_get function retrieves key/data pairs from the database. The -address and length of the key -are returned in the object referenced by key (except for the case -of the DB_SET flag where the key object is unchanged), -and the address and length of -the data are returned in the object referenced by data. -
Modifications to the database during a sequential scan will be reflected -in the scan, i.e. records inserted behind a cursor will not be returned -while records inserted in front of a cursor will be returned. -
In Queue and Recno databases, missing entries (i.e., entries that were -never explicitly created or that were created and then deleted), will be -skipped during a sequential scan. -
If multiple threads or processes insert items into the same database file -without using locking, the results are undefined. -For more detail, -see Cursor stability. -
The flags parameter must be set to one of the following values: -
If the cursor key/data pair was deleted, DBcursor->c_get will return -DB_KEYEMPTY. -
If the cursor is not yet initialized, the DBcursor->c_get function will return EINVAL. -
If the database is a Queue or Recno database, DBcursor->c_get using the -DB_FIRST (DB_LAST) flags will ignore any keys that exist -but were never explicitly created by the application or were created and -later deleted. -
If the database is empty, DBcursor->c_get will return DB_NOTFOUND. -
For DB_GET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM -flag. -
For DB_JOIN_ITEM to be specified, the underlying cursor must have -been returned from the DB->join function. -
If the database is a Queue or Recno database, DBcursor->c_get using the -DB_NEXT (DB_PREV) flag will skip any keys that exist but -were never explicitly created by the application or were created and later -deleted. -
If the cursor is already on the last (first) record in the database, -DBcursor->c_get will return DB_NOTFOUND. -
If the cursor is not yet initialized, the DBcursor->c_get function will return EINVAL. -
If the database is a Queue or Recno database, DBcursor->c_get using the -DB_NEXT_NODUP (DB_PREV_NODUP) flags will ignore any keys -that exist but were never explicitly created by the application or were -created and later deleted. -
If no non-duplicate key/data pairs occur after (before) the cursor -position in the database, DBcursor->c_get will return DB_NOTFOUND. -
In the presence of duplicate key values, DBcursor->c_get will return the -first data item for the given key. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -DBcursor->c_get will return DB_KEYEMPTY. -
If no matching keys are found, DBcursor->c_get will return -DB_NOTFOUND. -
For DB_SET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM -flag. -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
Otherwise, the DBcursor->c_get function returns a non-zero error value on failure and 0 on success. -
If DBcursor->c_get fails for any reason, the state of the cursor will be -unchanged. -
The DBcursor->c_get function may fail and return a non-zero error for the following conditions: -
The specified cursor was not currently initialized. -
The DBcursor->c_get function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBcursor->c_get function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbc_put.html b/bdb/docs/api_c/dbc_put.html deleted file mode 100644 index 9a8a0e8950a..00000000000 --- a/bdb/docs/api_c/dbc_put.html +++ /dev/null @@ -1,154 +0,0 @@ - - - - -
-
-DBcursor->c_put- |
-
-
- |
-#include <db.h> --int -DBcursor->c_put(DBC *, DBT *key, DBT *data, u_int32_t flags); -
The DBcursor->c_put function stores key/data pairs into the database. -
The flags parameter must be set to one of the following values: -
In the case of the Recno access method, it is an error to specify -DB_AFTER if the underlying Recno database was not created with -the DB_RENUMBER flag. If the DB_RENUMBER flag was -specified, a new key is created, all records after the inserted item -are automatically renumbered, and the key of the new record is returned -in the structure referenced by the parameter key. The initial -value of the key parameter is ignored. See DB->open -for more information. -
The DB_AFTER flag may not be specified to the Queue access method. -
If the current cursor record has already been deleted and the underlying -access method is Hash, DBcursor->c_put will return DB_NOTFOUND. -If the underlying access method is Btree or Recno, the operation will -succeed. -
If the cursor is not yet initialized or a duplicate sort function has been -specified, the DBcursor->c_put function will return EINVAL. -
In the case of the Recno access method, it is an error to specify -DB_BEFORE if the underlying Recno database was not created with -the DB_RENUMBER flag. If the DB_RENUMBER flag was -specified, a new key is created, the current record and all records -after it are automatically renumbered, and the key of the new record is -returned in the structure referenced by the parameter key. The -initial value of the key parameter is ignored. See -DB->open for more information. -
The DB_BEFORE flag may not be specified to the Queue access method. -
If the current cursor record has already been deleted and the underlying -access method is Hash, DBcursor->c_put will return DB_NOTFOUND. -If the underlying access method is Btree or Recno, the operation will -succeed. -
If the cursor is not yet initialized or a duplicate sort function has been -specified, DBcursor->c_put will return EINVAL. -
If a duplicate sort function has been specified and the data item of the -current referenced key/data pair does not compare equally to the data -parameter, DBcursor->c_put will return EINVAL. -
If the current cursor record has already been deleted and the underlying -access method is Hash, DBcursor->c_put will return DB_NOTFOUND. -If the underlying access method is Btree, Queue or Recno, the operation -will succeed. -
If the cursor is not yet initialized, DBcursor->c_put will return EINVAL. -
If the underlying database supports duplicate data items, and if the -key already exists in the database and a duplicate sort function has -been specified, the inserted data item is added in its sorted location. -If the key already exists in the database and no duplicate sort function -has been specified, the inserted data item is added as the first of the -data items for that key. -
The DB_KEYFIRST flag may not be specified to the Queue or Recno -access methods. -
If the underlying database supports duplicate data items, and if the -key already exists in the database and a duplicate sort function has -been specified, the inserted data item is added in its sorted location. -If the key already exists in the database, and no duplicate sort -function has been specified, the inserted data item is added as the last -of the data items for that key. -
The DB_KEYLAST flag may not be specified to the Queue or Recno -access methods. -
The DB_NODUPDATA flag may not be specified to the Queue or Recno -access methods. -
Otherwise, the DBcursor->c_put function returns a non-zero error value on failure and 0 on success. -
If DBcursor->c_put fails for any reason, the state of the cursor will be -unchanged. If DBcursor->c_put succeeds and an item is inserted into the -database, the cursor is always positioned to reference the newly inserted -item. -
The DBcursor->c_put function may fail and return a non-zero error for the following conditions: -
The DB_BEFORE or DB_AFTER flags were specified, and the -underlying access method is Queue. -
An attempt was made to add a record to a fixed-length database that was too -large to fit. -
The DBcursor->c_put function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBcursor->c_put function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbm.html b/bdb/docs/api_c/dbm.html deleted file mode 100644 index 783d59e6271..00000000000 --- a/bdb/docs/api_c/dbm.html +++ /dev/null @@ -1,220 +0,0 @@ - - - - -
-
-dbm/ndbm- |
-
-
- |
-#define DB_DBM_HSEARCH 1 -#include <db.h> --typedef struct { - char *dptr; - int dsize; -} datum; -
-Dbm Functions
-int -dbminit(char *file); --int -dbmclose(); -
-datum -fetch(datum key); -
-int -store(datum key, datum content); -
-int -delete(datum key); -
-datum -firstkey(void); -
-datum -nextkey(datum key); -
-Ndbm Functions
-DBM * -dbm_open(char *file, int flags, int mode); --void -dbm_close(DBM *db); -
-datum -dbm_fetch(DBM *db, datum key); -
-int -dbm_store(DBM *db, datum key, datum content, int flags); -
-int -dbm_delete(DBM *db, datum key); -
-datum -dbm_firstkey(DBM *db); -
-datum -dbm_nextkey(DBM *db); -
-int -dbm_error(DBM *db); -
-int -dbm_clearerr(DBM *db); -
The dbm interfaces to the Berkeley DB library are intended to provide -high-performance implementations and source code compatibility for -applications written to historic interfaces. They are not recommended -for any other purpose. The historic dbm database format -is not supported, and databases previously built using the real -dbm libraries cannot be read by the Berkeley DB functions. -
To compile dbm applications, replace the application's -#include of the dbm or ndbm include file (e.g., -#include <dbm.h> or #include <ndbm.h>) -with the following two lines: -
-#define DB_DBM_HSEARCH 1 -#include <db.h>
and recompile. If the application attempts to load against a dbm library -(e.g., -ldbm), remove the library from the load line. -
Key and content arguments are objects described by the -datum typedef. A datum specifies a string of -dsize bytes pointed to by dptr. Arbitrary binary data, -as well as normal text strings, is allowed. -
Before a database can be accessed, it must be opened by dbminit. -This will open and/or create the database file.db. If created, -the database file is created read/write by owner only (as described in -chmod(2) and modified by the process' umask value at the time -of creation (see umask(2)). The group ownership of created -files is based on the system and directory defaults, and is not further -specified by Berkeley DB. -
A database may be closed, and any held resources released, by calling -dbmclose. -
Once open, the data stored under a key is accessed by fetch and -data is placed under a key by store. A key (and its associated -contents) is deleted by delete. A linear pass through all keys -in a database may be made, in an (apparently) random order, by use of -firstkey and nextkey. The firstkey function will return -the first key in the database. The nextkey function will return the next -key in the database. -
The following code will traverse the data base: -
for (key = firstkey();
- key.dptr != NULL; key = nextkey(key)) {
- ...
-}Before a database can be accessed, it must be opened by dbm_open. -This will open and/or create the database file file.db depending -on the flags parameter (see open(2)). If created, the database -file is created with mode mode (as described in chmod(2)) and modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by -Berkeley DB. -
Once open, the data stored under a key is accessed by dbm_fetch -and data is placed under a key by dbm_store. The flags -field can be either DBM_INSERT or DBM_REPLACE. -DBM_INSERT will only insert new entries into the database and will -not change an existing entry with the same key. DBM_REPLACE will -replace an existing entry if it has the same key. A key (and its -associated contents) is deleted by dbm_delete. A linear pass -through all keys in a database may be made, in an (apparently) random -order, by use of dbm_firstkey and dbm_nextkey. The -dbm_firstkey function will return the first key in the database. The -dbm_nextkey function will return the next key in the database. -
The following code will traverse the data base: -
for (key = dbm_firstkey(db);
- key.dptr != NULL; key = dbm_nextkey(db)) {
- ...
-}The historic dbm library created two underlying database files, -traditionally named file.dir and file.pag. The Berkeley DB -library creates a single database file named file.db. -Applications that are aware of the underlying database file names may -require additional source code modifications. -
The historic dbminit interface required that the underlying -.dir and .pag files already exist (empty databases were -created by first manually creating zero-length .dir and -.pag files). Applications that expect to create databases using -this method may require additional source code modifications. -
The historic dbm_dirfno and dbm_pagfno macros are -supported, but will return identical file descriptors as there is only a -single underlying file used by the Berkeley DB hashing access method. -Applications using both file descriptors for locking may require -additional source code modifications. -
If applications using the dbm interface exits without first -closing the database, it may lose updates because the Berkeley DB library -buffers writes to underlying databases. Such applications will require -additional source code modifications to work correctly with the Berkeley DB -library. -
The dbminit function returns -1 on failure, setting errno, -and 0 on success. -
The fetch function sets the dptr field of the returned -datum to NULL on failure, setting errno, -and returns a non-NULL dptr on success. -
The store function returns -1 on failure, setting errno, -and 0 on success. -
The delete function returns -1 on failure, setting errno, -and 0 on success. -
The firstkey function sets the dptr field of the returned -datum to NULL on failure, setting errno, -and returns a non-NULL dptr on success. -
The nextkey function sets the dptr field of the returned -datum to NULL on failure, setting errno, -and returns a non-NULL dptr on success. -
The dbminit, fetch, store, delete, firstkey and nextkey functions may fail -and return a non-zero error for errors specified for other Berkeley DB and C -library or system functions. -
The dbm_close function returns non-zero when an error has occurred reading or -writing the database. -
The dbm_close function resets the error condition on the named database. -
The dbm_open function returns NULL on failure, setting errno, -and 0 on success. -
The dbm_fetch function sets the dptr field of the returned -datum to NULL on failure, setting errno, -and returns a non-NULL dptr on success. -
The dbm_store function returns -1 on failure, setting errno, -0 on success, and 1 if DBM_INSERT was set and the specified key already -existed in the database. -
The dbm_delete function returns -1 on failure, setting errno, -and 0 on success. -
The dbm_firstkey function sets the dptr field of the returned -datum to NULL on failure, setting errno, -and returns a non-NULL dptr on success. -
The dbm_nextkey function sets the dptr field of the returned -datum to NULL on failure, setting errno, -and returns a non-NULL dptr on success. -
The dbm_close function returns -1 on failure, setting errno, -and 0 on success. -
The dbm_close function returns -1 on failure, setting errno, -and 0 on success. -
The dbm_open, dbm_close, dbm_fetch, dbm_store, dbm_delete, dbm_firstkey -and dbm_nextkey functions may fail and return a non-zero error for errors -specified for other Berkeley DB and C library or system functions. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/dbt.html b/bdb/docs/api_c/dbt.html deleted file mode 100644 index a0c3e76db8d..00000000000 --- a/bdb/docs/api_c/dbt.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - -
-Storage and retrieval for the Berkeley DB access methods are based on key/data -pairs. Both key and data items are represented by the DBT data structure. -(The name DBT is a mnemonic for data base thang, and was used -because no one could think of a reasonable name that wasn't already in -use somewhere else.) Key and data byte strings may reference strings of -zero length up to strings of essentially unlimited length. See -Database limits for more -information. -
typedef struct {
- void *data;
- u_int32_t size;
- u_int32_t ulen;
- u_int32_t dlen;
- u_int32_t doff;
- u_int32_t flags;
-} DBT;In order to ensure compatibility with future releases of Berkeley DB, all fields -of the DBT structure that are not explicitly set should be initialized to -0 before the first time the structure is used. Do this by declaring the -structure external or static, or by calling the C library routine -bzero(3) or memset(3). -
By default, the flags structure element is expected to be 0. In -this default case, when the application is providing Berkeley DB a key or data -item to store into the database, Berkeley DB expects the data structure -element to point to a byte string of size bytes. When returning -a key/data item to the application, Berkeley DB will store into the data -structure element a pointer to a byte string of size bytes, and -the memory referenced by the pointer will be allocated and managed by Berkeley DB. -
The elements of the DBT structure are defined as follows: -
Note that applications can determine the length of a record by setting -the ulen field to 0 and checking the return value in the -size field. See the DB_DBT_USERMEM flag for more information. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
It is an error to specify more than one of DB_DBT_MALLOC, -DB_DBT_REALLOC and DB_DBT_USERMEM. -
The difference between DB_DBT_MALLOC and DB_DBT_REALLOC -is that the latter will call realloc(3) instead of -malloc(3), so the allocated memory will be grown as necessary -instead of the application doing repeated free/malloc calls. -
It is an error to specify more than one of DB_DBT_MALLOC, -DB_DBT_REALLOC and DB_DBT_USERMEM. -
It is an error to specify more than one of DB_DBT_MALLOC, -DB_DBT_REALLOC and DB_DBT_USERMEM. -
For example, if the data portion of a retrieved record was 100 bytes, -and a partial retrieval was done using a DBT having a dlen -field of 20 and a doff field of 85, the get call would succeed, -the data field would reference the last 15 bytes of the record, -and the size field would be set to 15. -
If the calling application is doing a put, the dlen bytes -starting doff bytes from the beginning of the specified key's -data record are replaced by the data specified by the data -and size structure elements. -If dlen is smaller than size, the record will grow, -and if dlen is larger than size, the record will shrink. -If the specified bytes do not exist, the record will be extended using -nul bytes as necessary, and the put call will succeed. -
It is an error to attempt a partial put using the DB->put function -in a database that supports duplicate records. -Partial puts in databases supporting duplicate records must be done -using a DBcursor->c_put function. -
It is an error to attempt a partial put with differing dlen and -size values in Queue or Recno databases with fixed-length records. -
For example, if the data portion of a retrieved record was 100 bytes, -and a partial put was done using a DBT having a dlen field of 20, -a doff field of 85, and a size field of 30, the resulting -record would be 115 bytes in length, where the last 30 bytes would be -those specified by the put call. -
When using the non-cursor Berkeley DB calls to retrieve key/data items (e.g., -DB->get), the memory referenced by the pointer stored into the -Dbt is only valid until the next call to Berkeley DB using the Db -handle returned by DB->open. (This includes any use of -the returned Db handle, including by another thread of control -within the process. For this reason, when multiple threads are using the -returned Db handle concurrently, one of the DB_DBT_MALLOC, -DB_DBT_REALLOC or DB_DBT_USERMEM flags must be specified -with any non-cursor Dbt used for key or data retrieval.) -
When using the cursor Berkeley DB calls to retrieve key/data items (e.g., -DBcursor->c_get), the memory referenced by the pointer into the -Dbt is only valid until the next call to Berkeley DB using the -DBC handle returned by DB->cursor. - -
The Berkeley DB access methods provide no guarantees about key/data byte string -alignment, and applications are responsible for arranging any necessary -alignment. The DB_DBT_MALLOC, DB_DBT_REALLOC and -DB_DBT_USERMEM flags may be used to store returned items in memory -of arbitrary alignment. - -
In all cases for the Queue and Recno access methods, and when calling the -DB->get and DBcursor->c_get functions with the -DB_SET_RECNO flag specified, the data field of the key -must be a pointer to a memory location of type db_recno_t, as -typedef'd in the #include <db.h> include file. This type is a 32-bit -unsigned type, (which limits the number of logical records in a Queue or -Recno database, and the maximum logical record which may be directly -retrieved from a Btree database, to 4,294,967,296). The size -field of the key should be the size of that type, i.e., in the C -programming language, sizeof(db_recno_t). -
Logical record numbers are 1-based, not 0-based, i.e., the first record -in the database is record number 1. - -
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_close.html b/bdb/docs/api_c/env_close.html deleted file mode 100644 index fdb11e2e18c..00000000000 --- a/bdb/docs/api_c/env_close.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-DBENV->close- |
-
-
- |
-#include <db.h> --int -DBENV->close(DB_ENV *dbenv, u_int32_t flags); -
The DBENV->close function closes the Berkeley DB environment, freeing any -allocated resources and closing any underlying subsystems. -
Calling DBENV->close does not imply closing any databases that were -opened in the environment. -
The flags parameter is currently unused, and must be set to 0. -
Where the environment was initialized with the DB_INIT_LOCK flag, -calling DBENV->close does not release any locks still held by the -closing process, providing functionality for long-lived locks. -Processes that wish to have all their locks -released can do so by issuing the appropriate lock_vec call. -
Where the environment was initialized with the DB_INIT_MPOOL -flag, calling DBENV->close implies calls to memp_fclose for -any remaining open files in the memory pool that were returned to this -process by calls to memp_fopen. It does not imply a call to -memp_fsync for those files. -
Where the environment was initialized with the DB_INIT_TXN flag, -calling DBENV->close aborts any uncommitted transactions. -(Applications are should not depend on this behavior. If the process' has -already closed a database handle which is necessary to abort an -uncommitted transaction, the Berkeley DB environment must then require that -recovery be run before further operations are done, since once a -transaction exists that cannot be committed or aborted, no future -checkpoint can ever succeed.) -
In multi-threaded applications, only a single thread may call -DBENV->close. -
Once DBENV->close has been called, regardless of its return, -the Berkeley DB environment handle may not be accessed again. -
The DBENV->close function returns a non-zero error value on failure and 0 on success. -
The DBENV->close function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBENV->close function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_create.html b/bdb/docs/api_c/env_create.html deleted file mode 100644 index 26ffb204ef2..00000000000 --- a/bdb/docs/api_c/env_create.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - -
-
-db_env_create- |
-
-
- |
-#include <db.h> --int -db_env_create(DB_ENV **dbenvp, u_int32_t flags); -
The db_env_create function creates a DB_ENV structure which is -the handle for a Berkeley DB environment. A pointer to this structure is -returned in the memory referenced by dbenvp. -
The flags parameter must be set to 0 or the following value: -
The DB_CLIENT flag indicates to the system that this environment -is remote on a server. The use of this flag causes the environment -methods to use functions that call a server instead of local functions. -Prior to making any environment or database method calls, the application -must call the DBENV->set_server function to establish the -connection to the server. -
The DB_ENV handle contains a special field, "app_private", which -is declared as type "void *". This field is provided for the use of -the application program. It is initialized to NULL and is not further -used by Berkeley DB in any way. -
The db_env_create function returns a non-zero error value on failure and 0 on success. -
The db_env_create function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the db_env_create function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_open.html b/bdb/docs/api_c/env_open.html deleted file mode 100644 index 677f40c1591..00000000000 --- a/bdb/docs/api_c/env_open.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - -
-
-DBENV->open- |
-
-
- |
-#include <db.h> --int -DBENV->open(DB_ENV *, char *db_home, u_int32_t flags, int mode); -
The DBENV->open function is the interface for opening the Berkeley DB -environment. It provides a structure for creating a consistent -environment for processes using one or more of the features of Berkeley DB. -
The db_home argument to DBENV->open (and file name -resolution in general) is described in -Berkeley DB File Naming. -
The flags argument specifies the subsystems that are initialized -and how the application's environment affects Berkeley DB file naming, among -other things. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
As there are a large number of flags that can be specified, they have been -grouped together by functionality. The first group of flags indicate -which of the Berkeley DB subsystems should be initialized: -
Access method calls are largely unchanged when using this flag, although -any cursors through which update operations (e.g., DBcursor->c_put, -DBcursor->c_del) will be made must have the DB_WRITECURSOR value -set in the flags parameter to the cursor call that creates the cursor. -See DB->cursor for more information. -
The log is stored in one or more files in the environment directory. -Each file is named using the format log.NNNNNNNNNN, where -NNNNNNNNNN is the sequence number of the file within the log. -For further information, see -Log File Limits. -
If the log region is being created and log files are already present, the -log files are reviewed and subsequent log writes are appended -to the end of the log, rather than overwriting current log entries. -
The second group of flags govern what recovery, if any, is performed when -the environment is initialized: -
A standard part of the recovery process is to remove the existing Berkeley DB -environment and create a new one in which to perform recovery. If the -thread of control performing recovery does not specify the correct region -initialization information (e.g., the correct memory pool cache size), -the result can be an application running in an environment with incorrect -cache and other subsystem sizes. For this reason, the thread of control -performing recovery should either specify correct configuration -information before calling the DBENV->open function, or it should remove -the environment after recovery is completed, leaving creation of the -correctly sized environment to a subsequent call to DBENV->open. -
All Berkeley DB recovery processing must be single-threaded, that is, only a -single thread of control may perform recovery or access a Berkeley DB -environment while recovery is being performed. As it is not an error to -specify DB_RECOVER for an environment for which no recovery is -required, it is reasonable programming practice for the thread of control -responsible for performing recovery and creating the environment to always -specify the DB_RECOVER flag during startup. -
The DBENV->open function returns successfully if DB_RECOVER -or DB_RECOVER_FATAL is specified and no log files exist, so it is -necessary to ensure all necessary log files are present before running -recovery. For further information, consult db_archive and -db_recover. -
The third group of flags govern file naming extensions in the environment: -
Finally, there are a few additional, unrelated flags: -
This flag should not be specified if more than a single process is -accessing the environment, as it is likely to cause database corruption -and unpredictable behavior, e.g., if both a server application and the -Berkeley DB utility db_stat will access the environment, the -DB_PRIVATE flag should not be specified. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by Berkeley DB -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
The DBENV->open function returns a non-zero error value on failure and 0 on success. -
The DBENV->open function may fail and return a non-zero error for the following conditions: -
-The DB_THREAD flag was specified and spinlocks are not -implemented for this architecture. -
The DB_HOME or TMPDIR environment variables were set but empty. -
An incorrectly formatted NAME VALUE entry or line was found. -
The DBENV->open function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBENV->open function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_remove.html b/bdb/docs/api_c/env_remove.html deleted file mode 100644 index 2d7279d79ab..00000000000 --- a/bdb/docs/api_c/env_remove.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - -
-
-DBENV->remove- |
-
-
- |
-#include <db.h> --int -DBENV->remove(DB_ENV *, char *db_home, u_int32_t flags); -
The DBENV->remove function destroys a Berkeley DB environment, if it is not -currently in use. The environment regions, including any backing files, -are removed. Any log or database files and the environment directory are -not removed. -
The db_home argument to DBENV->remove is described in -Berkeley DB File Naming. -
If there are processes that have called DBENV->open without -calling DBENV->close (i.e., there are processes currently using -the environment), DBENV->remove will fail without further action, -unless the DB_FORCE flag is set, in which case -DBENV->remove will attempt to remove the environment regardless -of any processes still using it. -
The result of attempting to forcibly destroy the environment when it is -in use is unspecified. Processes using an environment often maintain open -file descriptors for shared regions within it. On UNIX systems, the -environment removal will usually succeed and processes that have already -joined the region will continue to run in that region without change, -however processes attempting to join the environment will either fail or -create new regions. On other systems (e.g., Windows/NT), where the -unlink(2) system call will fail if any process has an open -file descriptor for the file, the region removal will fail. -
Calling DBENV->remove should not be necessary for most applications, -as the Berkeley DB environment is cleaned up as part of normal database recovery -procedures, however, applications may wish to call DBENV->remove -as part of application shutdown to free up system resources. -Specifically, when the DB_SYSTEM_MEM flag was specified to -DBENV->open, it may be useful to call DBENV->remove in order -to release system shared memory segments that have been allocated. -
In the case of catastrophic or system failure, database recovery must be -performed (see db_recover), or the DB_RECOVER and -DB_RECOVER_FATAL flags to DBENV->open must be specified -when the environment is re-opened. Alternatively, if recovery is not -required because no database state is maintained across failures, and -the DB_SYSTEM_MEM flag was not specified when the environment -was created, it is possible to clean up an environment by removing all -of the files in the environment directory that begin with the string -prefix "__db", as no backing files are created in any other directory. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
In multi-threaded applications, only a single thread may call -DBENV->remove. -
A DB_ENV handle which has already been used to open an -environment should not be used to call the DBENV->remove function, a new -DB_ENV handle should be created for that purpose. -
Once DBENV->remove has been called, regardless of its return, -the Berkeley DB environment handle may not be accessed again. -
The DBENV->remove function returns a non-zero error value on failure and 0 on success. -
The DBENV->remove function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the DBENV->remove function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_cachesize.html b/bdb/docs/api_c/env_set_cachesize.html deleted file mode 100644 index ba7980bb77a..00000000000 --- a/bdb/docs/api_c/env_set_cachesize.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - -
-
-DBENV->set_cachesize- |
-
-
- |
-#include <db.h> --int -DBENV->set_cachesize(DB_ENV *dbenv, - u_int32_t gbytes, u_int32_t bytes, int ncache); -
Set the size of the database's shared memory buffer pool, i.e., the cache, -to gbytes gigabytes plus bytes. The cache should be the -size of the normal working data set of the application, with some small -amount of additional memory for unusual situations. (Note, the working -set is not the same as the number of simultaneously referenced pages, and -should be quite a bit larger!) -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
The DBENV->set_cachesize interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_cachesize function returns a non-zero error value on failure and 0 on success. -
The database environment's cache size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_cachesize", one or more whitespace characters, -and the three arguments specified to this interface, separated by whitespace -characters, for example, "set_cachesize 1 500 2". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
The specified cache size was impossibly small. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_data_dir.html b/bdb/docs/api_c/env_set_data_dir.html deleted file mode 100644 index 68db6dc4725..00000000000 --- a/bdb/docs/api_c/env_set_data_dir.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DBENV->set_data_dir- |
-
-
- |
-#include <db.h> --int -DBENV->set_data_dir(DB_ENV *dbenv, const char *dir); -
Set the path of a directory to be used as the location of the access -method database files. Paths specified to the DB->open function -will be searched relative to this path. Paths set using this interface -are additive, and specifying more than one will result in each specified -directory being searched for database files. If any directories are -specified, created database files will always be created in the first path -specified. -
If no database directories are specified, database files can only exist -in the environment home directory. See Berkeley DB File Naming for more information. -
For the greatest degree of recoverability from system or application -failure, database files and log files should be located on separate -physical devices. -
The DBENV->set_data_dir interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_data_dir function returns a non-zero error value on failure and 0 on success. -
The database environment's data directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_data_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_errcall.html b/bdb/docs/api_c/env_set_errcall.html deleted file mode 100644 index 660943070ed..00000000000 --- a/bdb/docs/api_c/env_set_errcall.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - -
-
-DBENV->set_errcall- |
-
-
- |
-#include <db.h> --void -DBENV->set_errcall(DB_ENV *dbenv, - void (*db_errcall_fcn)(const char *errpfx, char *msg)); -
The DBENV->set_errcall function is used to enhance the mechanism for reporting error -messages to the application. In some cases, when an error occurs, Berkeley DB -will call db_errcall_fcn with additional error information. The -function must be declared with two arguments; the first will be the prefix -string (as previously set by DB->set_errpfx or -DBENV->set_errpfx), the second will be the error message string. -It is up to the db_errcall_fcn function to display the error -message in an appropriate manner. -
Alternatively, you can use the DB->set_errfile or -DBENV->set_errfile functions to display the additional information -via a C library FILE *. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
The DBENV->set_errcall interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_errfile.html b/bdb/docs/api_c/env_set_errfile.html deleted file mode 100644 index ba1dd75f2cc..00000000000 --- a/bdb/docs/api_c/env_set_errfile.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - -
-
-DBENV->set_errfile- |
-
-
- |
-#include <db.h> --void -DBENV->set_errfile(DB_ENV *dbenv, FILE *errfile); -
The DBENV->set_errfile function is used to enhance the mechanism for reporting error -messages to the application by setting a C library FILE * to be used for -displaying additional Berkeley DB error messages. In some cases, when an error -occurs, Berkeley DB will output an additional error message to the specified -file reference. -
The error message will consist of the prefix string and a colon -(":") (if a prefix string was previously specified using -DB->set_errpfx or DBENV->set_errpfx), an error string, and -a trailing <newline> character. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
The DBENV->set_errfile interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_errpfx.html b/bdb/docs/api_c/env_set_errpfx.html deleted file mode 100644 index be803070cce..00000000000 --- a/bdb/docs/api_c/env_set_errpfx.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-DBENV->set_errpfx- |
-
-
- |
-#include <db.h> --void -DBENV->set_errpfx(DB_ENV *dbenv, const char *errpfx); -
Set the prefix string that appears before error messages issued by Berkeley DB. -
The DBENV->set_errpfx function does not copy the memory referenced by the -errpfx argument, rather, it maintains a reference to it. This -allows applications to modify the error message prefix at any time, -without repeatedly calling DBENV->set_errpfx, but means that the -memory must be maintained until the handle is closed. -
The DBENV->set_errpfx interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_feedback.html b/bdb/docs/api_c/env_set_feedback.html deleted file mode 100644 index 743f7772ff9..00000000000 --- a/bdb/docs/api_c/env_set_feedback.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DBENV->set_feedback- |
-
-
- |
-#include <db.h> --int -DBENV->set_feedback(DB_ENV *, - void (*db_feedback_fcn)(DB_ENV *, int opcode, int pct)); -
Some operations performed by the Berkeley DB library can take non-trivial -amounts of time. The DBENV->set_feedback function can be used by -applications to monitor progress within these operations. -
When an operation is likely to take a long time, Berkeley DB will call the -specified callback function. This function must be declared with -three arguments: the first will be a reference to the enclosing -environment, the second a flag value, and the third the percent of the -operation that has been completed, specified as an integer value between -0 and 100. It is up to the callback function to display this -information in an appropriate manner. -
The opcode argument may take on any of the following values: -
The DBENV->set_feedback interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DBENV->set_feedback function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_flags.html b/bdb/docs/api_c/env_set_flags.html deleted file mode 100644 index 6dfc0950819..00000000000 --- a/bdb/docs/api_c/env_set_flags.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-DBENV->set_flags- |
-
-
- |
-#include <db.h> --int -DBENV->set_flags(DB_ENV *dbenv, u_int32_t flags, int onoff); -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -If onoff is zero, the specified flags are cleared, otherwise they -are set. -
The number of transactions that are potentially at risk is governed by -how often the log is checkpointed (see db_checkpoint for more -information) and how many log updates can fit on a single log page. -
The DBENV->set_flags function returns a non-zero error value on failure and 0 on success. -
The database environment's flag values may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_flags", one or more whitespace characters, -and the interface flag argument as a string, for example, "set_flags -DB_TXN_NOSYNC". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lg_bsize.html b/bdb/docs/api_c/env_set_lg_bsize.html deleted file mode 100644 index 85e6dc12118..00000000000 --- a/bdb/docs/api_c/env_set_lg_bsize.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DBENV->set_lg_bsize- |
-
-
- |
-#include <db.h> --int -DBENV->set_lg_bsize(DB_ENV *dbenv, u_int32_t lg_bsize); -
Set the size of the in-memory log buffer, in bytes. By default, or if -the value is set to 0, a size of 32K is used. -
Log information is stored in-memory until the storage space fills up -or transaction commit forces the information to be flushed to stable -storage. In the presence of long-running transactions or transactions -producing large amounts of data, larger buffer sizes can increase -throughput. -
The DBENV->set_lg_bsize interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lg_bsize function returns a non-zero error value on failure and 0 on success. -
The database environment's log buffer size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_bsize", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lg_dir.html b/bdb/docs/api_c/env_set_lg_dir.html deleted file mode 100644 index a8d5c861421..00000000000 --- a/bdb/docs/api_c/env_set_lg_dir.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - -
-
-DBENV->set_lg_dir- |
-
-
- |
-#include <db.h> --int -DBENV->set_lg_dir(DB_ENV *dbenv, const char *dir); -
The path of a directory to be used as the location of logging files. -Log files created by the Log Manager subsystem will be created in this -directory. -
If no logging directory is specified, log files are created in the -environment home directory. See Berkeley DB File Naming for more information. -
For the greatest degree of recoverability from system or application -failure, database files and log files should be located on separate -physical devices. -
The DBENV->set_lg_dir interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lg_dir function returns a non-zero error value on failure and 0 on success. -
The database environment's logging directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lg_max.html b/bdb/docs/api_c/env_set_lg_max.html deleted file mode 100644 index 4625db4346b..00000000000 --- a/bdb/docs/api_c/env_set_lg_max.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DBENV->set_lg_max- |
-
-
- |
-#include <db.h> --int -DBENV->set_lg_max(DB_ENV *dbenv, u_int32_t lg_max); -
Set the maximum size of a single file in the log, in bytes. Because -DB_LSN file offsets are unsigned 4-byte values, the set value may -not be larger than the maximum unsigned 4-byte value. By default, or if -the value is set to 0, a size of 10MB is used. -
See Log File Limits -for more information. -
The DBENV->set_lg_max interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lg_max function returns a non-zero error value on failure and 0 on success. -
The database environment's log file size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_max", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
The specified log file size was too large. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lk_conflicts.html b/bdb/docs/api_c/env_set_lk_conflicts.html deleted file mode 100644 index 689464736ef..00000000000 --- a/bdb/docs/api_c/env_set_lk_conflicts.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DBENV->set_lk_conflicts- |
-
-
- |
-#include <db.h> --int -DBENV->set_lk_conflicts(DB_ENV *dbenv, - u_int8_t *conflicts, int nmodes); -
Set the locking conflicts matrix. -The conflicts argument -is an nmodes by nmodes array. -A non-0 value for the array element: -
-conflicts[requested_mode][held_mode]
indicates that requested_mode and held_mode conflict. The -not-granted mode must be represented by 0. -
If no conflicts value is specified, the conflicts array -db_rw_conflicts is used; see Standard Lock Modes for a description of that array. -
The DBENV->set_lk_conflicts interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lk_conflicts function returns a non-zero error value on failure and 0 on success. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lk_detect.html b/bdb/docs/api_c/env_set_lk_detect.html deleted file mode 100644 index 460651a0dab..00000000000 --- a/bdb/docs/api_c/env_set_lk_detect.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-DBENV->set_lk_detect- |
-
-
- |
-#include <db.h> --int -DBENV->set_lk_detect(DB_ENV *dbenv, u_int32_t detect); -
Set if the deadlock detector is to be run whenever a lock conflict occurs, -and specify which transaction should be aborted in the case of a deadlock. -The specified value must be one of the following list: -
The DBENV->set_lk_detect interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lk_detect function returns a non-zero error value on failure and 0 on success. -
The database environment's deadlock detector configuration may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_detect", one or more whitespace characters, -and the interface detect argument as a string, for example, -"set_lk_detect DB_LOCK_OLDEST". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lk_max.html b/bdb/docs/api_c/env_set_lk_max.html deleted file mode 100644 index 1e9832b59d9..00000000000 --- a/bdb/docs/api_c/env_set_lk_max.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-DBENV->set_lk_max- |
-
-
- |
-#include <db.h> --int -DBENV->set_lk_max(DB_ENV *dbenv, u_int32_t max); -
The DBENV->set_lk_max function interface has been deprecated in favor of -the DBENV->set_lk_max_locks, DBENV->set_lk_max_lockers, -and DBENV->set_lk_max_objects functions. Please update your applications. -
Set each of the maximum number of locks, lockers and lock objects -supported by the Berkeley DB lock subsystem to max. This value is -used by DBENV->open to estimate how much space to allocate for -various lock-table data structures. For specific information on -configuring the size of the lock subsystem, see -Configuring locking: sizing the -system. -
The DBENV->set_lk_max interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lk_max function returns a non-zero error value on failure and 0 on success. -
The database environment's maximum number of locks may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max", one or more whitespace characters, -and the number of locks. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lk_max_lockers.html b/bdb/docs/api_c/env_set_lk_max_lockers.html deleted file mode 100644 index e41a943fd56..00000000000 --- a/bdb/docs/api_c/env_set_lk_max_lockers.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DBENV->set_lk_max_lockers- |
-
-
- |
-#include <db.h> --int -DBENV->set_lk_max_lockers(DB_ENV *dbenv, u_int32_t max); -
Set the maximum number of simultaneous locking entities supported by -the Berkeley DB lock subsystem. This value is used by DBENV->open to -estimate how much space to allocate for various lock-table data -structures. For specific information on configuring the size of the -lock subsystem, see -Configuring locking: sizing the system. -
The DBENV->set_lk_max_lockers interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lk_max_lockers function returns a non-zero error value on failure and 0 on success. -
The database environment's maximum number of lockers may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_lockers", one or more whitespace characters, -and the number of lockers. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lk_max_locks.html b/bdb/docs/api_c/env_set_lk_max_locks.html deleted file mode 100644 index a908b288f97..00000000000 --- a/bdb/docs/api_c/env_set_lk_max_locks.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-DBENV->set_lk_max_locks- |
-
-
- |
-#include <db.h> --int -DBENV->set_lk_max_locks(DB_ENV *dbenv, u_int32_t max); -
Set the maximum number of locks supported by the Berkeley DB lock subsystem. -This value is used by DBENV->open to estimate how much space to -allocate for various lock-table data structures. For specific -information on configuring the size of the lock subsystem, see -Configuring locking: sizing the system. -
The DBENV->set_lk_max_locks interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lk_max_locks function returns a non-zero error value on failure and 0 on success. -
The database environment's maximum number of locks may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_locks", one or more whitespace characters, -and the number of locks. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_lk_max_objects.html b/bdb/docs/api_c/env_set_lk_max_objects.html deleted file mode 100644 index 8fba15876cf..00000000000 --- a/bdb/docs/api_c/env_set_lk_max_objects.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DBENV->set_lk_max_objects- |
-
-
- |
-#include <db.h> --int -DBENV->set_lk_max_objects(DB_ENV *dbenv, u_int32_t max); -
Set the maximum number of simultaneously locked objects supported by -the Berkeley DB lock subsystem. This value is used by DBENV->open to -estimate how much space to allocate for various lock-table data -structures. For specific information on configuring the size of the -lock subsystem, see -Configuring locking: sizing the system. -
The DBENV->set_lk_max_objects interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_lk_max_objects function returns a non-zero error value on failure and 0 on success. -
The database environment's maximum number of objects may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_objects", one or more whitespace characters, -and the number of objects. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_mp_mmapsize.html b/bdb/docs/api_c/env_set_mp_mmapsize.html deleted file mode 100644 index 3f87a140a15..00000000000 --- a/bdb/docs/api_c/env_set_mp_mmapsize.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DBENV->set_mp_mmapsize- |
-
-
- |
-#include <db.h> --int -DBENV->set_mp_mmapsize(DB_ENV *dbenv, size_t mp_mmapsize); -
Files that are opened read-only in the pool (and that satisfy a few other -criteria) are, by default, mapped into the process address space instead -of being copied into the local cache. This can result in better-than-usual -performance, as available virtual memory is normally much larger than the -local cache, and page faults are faster than page copying on many systems. -However, in the presence of limited virtual memory it can cause resource -starvation, and in the presence of large databases, it can result in immense -process sizes. -
Set the maximum file size, in bytes, for a file to be mapped into the -process address space. If no value is specified, it defaults to 10MB. -
The DBENV->set_mp_mmapsize interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_mp_mmapsize function returns a non-zero error value on failure and 0 on success. -
The database environment's maximum mapped file size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_mp_mmapsize", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_mutexlocks.html b/bdb/docs/api_c/env_set_mutexlocks.html deleted file mode 100644 index a5fa2aa34c6..00000000000 --- a/bdb/docs/api_c/env_set_mutexlocks.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-DBENV->set_mutexlocks- |
-
-
- |
-#include <db.h> --int -DBENV->set_mutexlocks(DB_ENV *dbenv, int do_lock); -
Toggle mutex locks. Setting do_lock to a zero value causes -Berkeley DB to grant all requested mutual exclusion mutexes without regard -for their availability. -
This functionality should never be used for any other purpose than -debugging. -
The DBENV->set_mutexlocks interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DBENV->set_mutexlocks function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_pageyield.html b/bdb/docs/api_c/env_set_pageyield.html deleted file mode 100644 index 95372408525..00000000000 --- a/bdb/docs/api_c/env_set_pageyield.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-db_env_set_pageyield- |
-
-
- |
-#include <db.h> --int -db_env_set_pageyield(int pageyield); -
Yield the processor whenever requesting a page from the cache. Setting -pageyield to a non-zero value causes Berkeley DB to yield the processor -any time a thread requests a page from the cache. -
The db_env_set_pageyield interface affects the entire application, not a single -database or database environment. -
While the db_env_set_pageyield interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
This functionality should never be used for any other purpose than stress -testing. -
The db_env_set_pageyield interface may be used to configure Berkeley DB at any time -during the life of the application. -
The db_env_set_pageyield function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_paniccall.html b/bdb/docs/api_c/env_set_paniccall.html deleted file mode 100644 index a9d58a80b83..00000000000 --- a/bdb/docs/api_c/env_set_paniccall.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - - -
-
-DBENV->set_paniccall- |
-
-
- |
-#include <db.h> --int -DBENV->set_paniccall(DB_ENV *dbenv, - void (*paniccall)(DB_ENV *, int errval)); -
Errors can occur in the Berkeley DB library where the only solution is to shut -down the application and run recovery. (For example, if Berkeley DB is unable -to write log records to disk because there is insufficient disk space.) -In these cases, the value DB_RUNRECOVERY is returned by Berkeley DB. -
In these cases, it is also often simpler to shut down the application when -such errors occur rather than attempting to gracefully return up the stack. -The DBENV->set_paniccall function is used to specify a function to be called when -DB_RUNRECOVERY is about to be returned from a Berkeley DB method. When -called, the dbenv argument will be a reference to the current -environment, and the errval argument is the error value that would -have been returned to the calling function. -
The DBENV->set_paniccall interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DBENV->set_paniccall function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_panicstate.html b/bdb/docs/api_c/env_set_panicstate.html deleted file mode 100644 index 6168ad9af7e..00000000000 --- a/bdb/docs/api_c/env_set_panicstate.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - -
-
-db_env_set_panicstate- |
-
-
- |
-#include <db.h> --int -db_env_set_panicstate(int panic); -
Toggle the Berkeley DB panic state. Setting panic to a non-zero value -causes Berkeley DB to refuse attempts to call Berkeley DB functions with the -DB_RUNRECOVERY error return. -
The db_env_set_panicstate interface affects the entire application, not a single -database or database environment. -
While the db_env_set_panicstate interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_panicstate function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_rec_init.html b/bdb/docs/api_c/env_set_rec_init.html deleted file mode 100644 index 056ec9b717c..00000000000 --- a/bdb/docs/api_c/env_set_rec_init.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DBENV->set_recovery_init- |
-
-
- |
-#include <db.h> --int -DBENV->set_recovery_init(DB_ENV *, - int (*db_recovery_init_fcn)(DB_ENV *)); -
Applications installing application-specific recovery functions need -to be called before Berkeley DB performs recovery so they may add their recovery -functions to Berkeley DB's. -
The DBENV->set_recovery_init function supports this functionality. The -db_recovery_init_fcn function must be declared with one -argument, a reference to the enclosing Berkeley DB environment. This -function will be called after the DBENV->open has been called, -but before recovery is started. -
If the db_recovery_init_fcn function returns a non-zero value, -no recovery will be performed and DBENV->open will return the same -value to its caller. -
The DBENV->set_recovery_init interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_recovery_init function returns a non-zero error value on failure and 0 on success. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_region_init.html b/bdb/docs/api_c/env_set_region_init.html deleted file mode 100644 index 3c83680ada9..00000000000 --- a/bdb/docs/api_c/env_set_region_init.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-db_env_set_region_init- |
-
-
- |
-#include <db.h> --int -db_env_set_region_init(int region_init); -
Page-fault shared regions into memory when initially creating or joining -a Berkeley DB environment. In some applications, the expense of page-faulting -the shared memory regions can affect performance, e.g., when the -page-fault occurs while holding a lock, other lock requests can convoy -and overall throughput may decrease. Setting region_init to a -non-zero value specifies that shared regions be read or written, as -appropriate, when the region is joined by the application. This forces -the underlying virtual memory and file systems to instantiate both the -necessary memory and the necessary disk space. This can also avoid -out-of-disk space failures later on. -
The db_env_set_region_init interface affects the entire application, not a single -database or database environment. -
While the db_env_set_region_init interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_region_init function returns a non-zero error value on failure and 0 on success. -
The database environment's initial behavior with respect to shared memory regions may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_region_init", one or more whitespace characters, -and the string "1". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_server.html b/bdb/docs/api_c/env_set_server.html deleted file mode 100644 index 586887bfc96..00000000000 --- a/bdb/docs/api_c/env_set_server.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DBENV->set_server- |
-
-
- |
-#include <db.h> --int -DBENV->set_server(DB_ENV *dbenv, char *host, - long cl_timeout, long sv_timeout, u_int32_t flags); -
Connects to the DB server on the indicated hostname and sets up a channel -for communication. -
The cl_timeout argument specifies the number of seconds the client -should wait for results to come back from the server. Once the timeout -has expired on any communication with the server, DB_NOSERVER will -be returned. If this value is zero, a default timeout is used. -
The sv_timeout argument specifies the number of seconds the server -should allow a client connection to remain idle before assuming that -client is gone. Once that timeout has been reached, the server releases -all resources associated with that client connection. Subsequent attempts -by that client to communicate with the server result in -DB_NOSERVER_ID indicating that an invalid identifier has been -given to the server. This value can be considered a hint to the server. -The server may alter this value based on its own policies or allowed -values. If this value is zero, a default timeout is used. -
The flags parameter is currently unused, and must be set to 0. -
When the DBENV->set_server function has been called, any subsequent calls -to Berkeley DB library interfaces may return either DB_NOSERVER or -DB_NOSERVER_ID. -
The DBENV->set_server function returns a non-zero error value on failure and 0 on success. -
dbenv_set_server -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_shm_key.html b/bdb/docs/api_c/env_set_shm_key.html deleted file mode 100644 index 8de32ed842a..00000000000 --- a/bdb/docs/api_c/env_set_shm_key.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-DBENV->set_shm_key- |
-
-
- |
-#include <db.h> --int -DBENV->set_shm_key(DB_ENV *dbenv, long shm_key); -
Specify a base segment ID for Berkeley DB environment shared memory regions -created in system memory on VxWorks or systems supporting X/Open-style -shared memory interfaces, e.g., UNIX systems supporting -shmget(2) and related System V IPC interfaces. -
This base segment ID will be used when Berkeley DB shared memory regions are -first created. It will be incremented a small integer value each time -a new shared memory region is created, that is, if the base ID is 35, -the first shared memory region created will have a segment ID of 35 and -the next one a segment ID between 36 and 40 or so. A Berkeley DB environment -always creates a master shared memory region, plus an additional shared -memory region for each of the subsystems supported by the environment -(locking, logging, memory pool and transaction), plus an additional -shared memory region for each additional memory pool cache that is -supported. Already existing regions with the same segment IDs will be -removed. See Shared Memory Regions -for more information. -
The intent behind this interface is two-fold: without it, applications -have no way to ensure that two Berkeley DB applications don't attempt to use -the same segment IDs when creating different Berkeley DB environments. In -addition, by using the same segment IDs each time the environment is -created, previously created segments will be removed, and the set of -segments on the system will not grow without bound. -
The DBENV->set_shm_key interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_shm_key function returns a non-zero error value on failure and 0 on success. -
The database environment's base segment ID may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_shm_key", one or more whitespace characters, -and the ID. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_tas_spins.html b/bdb/docs/api_c/env_set_tas_spins.html deleted file mode 100644 index 633dcda077e..00000000000 --- a/bdb/docs/api_c/env_set_tas_spins.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - -
-
-db_env_set_tas_spins- |
-
-
- |
-#include <db.h> --int -db_env_set_tas_spins(u_int32_t tas_spins); -
Specify that test-and-set mutexes should spin tas_spins times -without blocking. The value defaults to 1 on uniprocessor systems and -to 50 times the number of processors on multiprocessor systems. -
The db_env_set_tas_spins interface affects the entire application, not a single -database or database environment. -
While the db_env_set_tas_spins interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_tas_spins function returns a non-zero error value on failure and 0 on success. -
The database environment's test-and-set spin count may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tas_spins", one or more whitespace characters, -and the number of spins. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_tmp_dir.html b/bdb/docs/api_c/env_set_tmp_dir.html deleted file mode 100644 index 05f3bed5da0..00000000000 --- a/bdb/docs/api_c/env_set_tmp_dir.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - -
-
-DBENV->set_tmp_dir- |
-
-
- |
-#include <db.h> --int -DBENV->set_tmp_dir(DB_ENV *dbenv, const char *dir); -
The path of a directory to be used as the location of temporary files. -The files created to back in-memory access method databases will be -created relative to this path. These temporary files can be quite large, -depending on the size of the database. -
If no directories are specified, the following alternatives are checked -in the specified order. The first existing directory path is used for -all temporary files. -
Note: environment variables are only checked if one of the -DB_USE_ENVIRON or DB_USE_ENVIRON_ROOT flags were -specified. -
Note: the GetTempPath interface is only checked on Win/32 platforms. -
The DBENV->set_tmp_dir interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_tmp_dir function returns a non-zero error value on failure and 0 on success. -
The database environment's temporary file directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tmp_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_tx_max.html b/bdb/docs/api_c/env_set_tx_max.html deleted file mode 100644 index 82328955237..00000000000 --- a/bdb/docs/api_c/env_set_tx_max.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-DBENV->set_tx_max- |
-
-
- |
-#include <db.h> --int -DBENV->set_tx_max(DB_ENV *dbenv, u_int32_t tx_max); -
Set the maximum number of active transactions that are supported by the -environment. This value bounds the size of backing shared memory regions. -Note that child transactions must be counted as active until their -ultimate parent commits or aborts. -
When there are more than the specified number of concurrent transactions, -calls to txn_begin will fail (until some active transactions -complete). If no value is specified, a default value of 20 is used. -
The DBENV->set_tx_max interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_tx_max function returns a non-zero error value on failure and 0 on success. -
The database environment's maximum number of active transactions may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tx_max", one or more whitespace characters, -and the number of transactions. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_tx_recover.html b/bdb/docs/api_c/env_set_tx_recover.html deleted file mode 100644 index 9295537b5f5..00000000000 --- a/bdb/docs/api_c/env_set_tx_recover.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-DBENV->set_tx_recover- |
-
-
- |
-#include <db.h> --int -DBENV->set_tx_recover(DB_ENV *dbenv, - int (*tx_recover)(DB_ENV *dbenv, - DBT *log_rec, DB_LSN *lsn, db_recops op)); -
Set the application's function to be called during transaction abort -and recovery. This function must return 0 on success and either -errno or a value outside of the Berkeley DB error name space on -failure. It takes four arguments: -
The DBENV->set_tx_recover interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_tx_recover function returns a non-zero error value on failure and 0 on success. -
Called after DBENV->open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_tx_timestamp.html b/bdb/docs/api_c/env_set_tx_timestamp.html deleted file mode 100644 index 68cd0d15723..00000000000 --- a/bdb/docs/api_c/env_set_tx_timestamp.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-DBENV->set_tx_timestamp- |
-
-
- |
-#include <db.h> --int -DBENV->set_tx_timestamp(DB_ENV *dbenv, time_t *timestamp); -
Recover to the time specified by timestamp rather than to the most -current possible date. -The timestamp argument should be the number of seconds since 0 -hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time, -i.e., the Epoch. -
Once a database environment has been upgraded to a new version of Berkeley DB -involving a log format change (see Upgrading Berkeley DB installations, it is no longer possible to recover -to a specific time before that upgrade. -
The DBENV->set_tx_timestamp interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The DBENV->set_tx_timestamp function returns a non-zero error value on failure and 0 on success. -
It is not possible to recover to the specified time using the -log files currently present in the environment. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_set_verbose.html b/bdb/docs/api_c/env_set_verbose.html deleted file mode 100644 index 605fd577cca..00000000000 --- a/bdb/docs/api_c/env_set_verbose.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - -
-
-DBENV->set_verbose- |
-
-
- |
-#include <db.h> --int -DBENV->set_verbose(DB_ENV *dbenv, u_int32_t which, int onoff); -
The DBENV->set_verbose function turns additional informational and -debugging messages in the Berkeley DB message output on and off. If -onoff is set to -non-zero, -the additional messages are output. -
The which parameter must be set to one of the following values: -
The DBENV->set_verbose interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DBENV->set_verbose function returns a non-zero error value on failure and 0 on success. -
The database environment's verbosity may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_verbose", one or more whitespace characters, -and the interface which argument as a string, for example, -"set_verbose DB_VERB_CHKPOINT". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_strerror.html b/bdb/docs/api_c/env_strerror.html deleted file mode 100644 index e6bd190a2ea..00000000000 --- a/bdb/docs/api_c/env_strerror.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - -
-
-db_strerror- |
-
-
- |
-#include <db.h> --char * -db_strerror(int error); -
The db_strerror function returns an error message string corresponding -to the error number error. This interface is a superset of the -ANSI C X3.159-1989 (ANSI C) strerror(3) interface. If the error number -error is greater than or equal to 0, then the string returned by -the system interface strerror(3) is returned. If the error -number is less than 0, an error string appropriate to the corresponding -Berkeley DB library error is returned. See -Error returns to applications -for more information. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/env_version.html b/bdb/docs/api_c/env_version.html deleted file mode 100644 index fa7704aaea2..00000000000 --- a/bdb/docs/api_c/env_version.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - -
-
-db_version- |
-
-
- |
-#include <db.h> --char * -db_version(int *major, int *minor, int *patch); -
The db_version function returns a pointer to a string containing Berkeley DB -version information. If major is non-NULL, the major version -of the Berkeley DB release is stored in the memory it references. If -minor is non-NULL, the minor version of the Berkeley DB release is -stored in the memory it references. If patch is non-NULL, the -patch version of the Berkeley DB release is stored in the memory it references. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/hsearch.html b/bdb/docs/api_c/hsearch.html deleted file mode 100644 index 0d6d6ce51ed..00000000000 --- a/bdb/docs/api_c/hsearch.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - -
-
-hsearch- |
-
-
- |
-#define DB_DBM_HSEARCH 1 -#include <db.h> --typedef enum { - FIND, ENTER -} ACTION; -
-typedef struct entry { - char *key; - void *data; -} ENTRY; -
-ENTRY * -hsearch(ENTRY item, ACTION action); -
-int -hcreate(size_t nelem); -
-void -hdestroy(void); -
The hsearch interface to the Berkeley DB library is intended to -provide a high-performance implementation and source code compatibility -for applications written to the historic hsearch interface. -It is not recommended for any other purpose. -
To compile hsearch applications, replace the application's -#include of the hsearch include -file (e.g., #include <search.h>) -with the following two lines: -
--#define DB_DBM_HSEARCH 1 -#include <db.h>
and recompile. -
The hcreate function creates an in-memory database. The -nelem argument is an estimation of the maximum number of key/data -pairs that will be stored in the database. -
The hdestroy function discards the database. -
Database elements are structures of type ENTRY, which contain at -least two fields: key and data. The field key is -declared to be of type char * and is the key used for storage -and retrieval. The field data is declared to be of type -void * and is its associated data. -
The hsearch function retrieves key/data pairs from, and stores -key/data pairs into the database. -
The action argument must be set to one of two values: -
Historically, hsearch required applications to maintain the keys -and data in the application's memory for as long as the hsearch -database existed. As Berkeley DB handles key and data management internally, -there is no requirement that applications maintain local copies of key -and data items, although the only effect of doing so should be the -allocation of additional memory. -
The hcreate function returns 0 on failure, setting errno -and non-zero on success. -
The hsearch function returns a pointer to an ENTRY structure on -success, and NULL, setting errno, if the action -specified was FIND and the item did not appear in the database. -
The hcreate function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the hcreate function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
The hsearch function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the hsearch function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
In addition, the hsearch function will fail, setting errno -to 0, if the action specified was FIND and the item did not appear in -the database. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/lock_detect.html b/bdb/docs/api_c/lock_detect.html deleted file mode 100644 index 7b95e98e9d0..00000000000 --- a/bdb/docs/api_c/lock_detect.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - -
-
-lock_detect- |
-
-
- |
-#include <db.h> --int -lock_detect(DB_ENV *env, - u_int32_t flags, u_int32_t atype, int *aborted); -
The lock_detect function runs one iteration of the deadlock detector. -The deadlock detector traverses the lock table, and for each deadlock -it finds, marks one of the participating transactions for abort. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The atype parameter specifies which transaction to abort in the -case of deadlock. It must be set to one of possible arguments listed for -the DBENV->set_lk_detect interface. -
If the aborted parameter is non-NULL, the memory location it -references will be set to the number of transactions aborted by the -lock_detect function. -
The lock_detect function is the underlying function used by the db_deadlock utility. -See the db_deadlock utility source code for an example of using lock_detect -in a IEEE/ANSI Std 1003.1 (POSIX) environment. -
The lock_detect function returns a non-zero error value on failure and 0 on success. -
The lock_detect function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the lock_detect function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/lock_get.html b/bdb/docs/api_c/lock_get.html deleted file mode 100644 index 8d68ba54cb9..00000000000 --- a/bdb/docs/api_c/lock_get.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - -
-
-lock_get- |
-
-
- |
-#include <db.h> --int -lock_get(DB_ENV *env, u_int32_t locker, - u_int32_t flags, const DBT *obj, - const db_lockmode_t lock_mode, DB_LOCK *lock); -
The lock_get function acquires a lock from the lock table, returning -information about it in -the lock argument. -
The locker argument specified to lock_get is an unsigned -32-bit integer quantity. It represents the entity requesting or releasing -the lock. -
The flags value must be set to 0 or the following value: -
The obj argument is an untyped byte string that specifies the -object to be locked or released. -
The mode argument is an index into the environment's lock conflict -array. See DBENV->set_lk_conflicts and -Standard Lock Modes -for a description of that array. -
The lock_get function may -return -one of the following values: -
Otherwise, the lock_get function returns a non-zero error value on failure and 0 on success. -
The lock_get function may fail and return a non-zero error for the following conditions: -
The lock_get function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the lock_get function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/lock_id.html b/bdb/docs/api_c/lock_id.html deleted file mode 100644 index bd720cdb00e..00000000000 --- a/bdb/docs/api_c/lock_id.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - -
-
-lock_id- |
-
-
- |
-#include <db.h> --int -lock_id(DB_ENV *env, u_int32_t *idp); -
The lock_id function -copies a locker ID, which is guaranteed to be unique in the specified lock -table, into the memory location referenced by idp. -
The lock_id function returns a non-zero error value on failure and 0 on success. -
The lock_id function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the lock_id function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/lock_put.html b/bdb/docs/api_c/lock_put.html deleted file mode 100644 index 777f4bdd09b..00000000000 --- a/bdb/docs/api_c/lock_put.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-lock_put- |
-
-
- |
-#include <db.h> --int -lock_put(DB_ENV *env, DB_LOCK *lock); -
The lock_put function releases lock from the lock table. -
The lock_put function returns a non-zero error value on failure and 0 on success. -
The lock_put function may fail and return a non-zero error for the following conditions: -
The lock_put function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the lock_put function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/lock_stat.html b/bdb/docs/api_c/lock_stat.html deleted file mode 100644 index c86024de7f9..00000000000 --- a/bdb/docs/api_c/lock_stat.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-lock_stat- |
-
-
- |
-#include <db.h> --int -lock_stat(DB_ENV *env, - DB_LOCK_STAT **statp, void *(*db_malloc)(size_t)); -
The lock_stat function -creates a statistical structure and copies a pointer to it into a -user-specified memory location. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The lock region statistics are stored in a structure of type -DB_LOCK_STAT. The following DB_LOCK_STAT fields will be filled in: -
The lock_stat function returns a non-zero error value on failure and 0 on success. -
The lock_stat function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the lock_stat function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/lock_vec.html b/bdb/docs/api_c/lock_vec.html deleted file mode 100644 index 56d3fa96a98..00000000000 --- a/bdb/docs/api_c/lock_vec.html +++ /dev/null @@ -1,123 +0,0 @@ - - - - -
-
-lock_vec- |
-
-
- |
-#include <db.h> --int -lock_vec(DB_ENV *env, u_int32_t locker, u_int32_t flags, - DB_LOCKREQ list[], int nlist, DB_LOCKREQ **elistp); -
The lock_vec function atomically obtains and releases one or more locks -from the lock table. The lock_vec function is intended to support -acquisition or trading of multiple locks under one lock table semaphore, -as is needed for lock coupling or in multigranularity locking for lock -escalation. -
The locker argument specified to lock_vec is an unsigned -32-bit integer quantity. It represents the entity requesting or releasing -the lock. -
The flags value must be set to 0 or the following value: -
The list array provided to lock_vec is typedef'd as -DB_LOCKREQ. A DB_LOCKREQ structure has at least the following fields, -which must be initialized before calling lock_vec: -
The nlist argument specifies the number of elements in the -list array. -
If any of the requested locks cannot be acquired, or any of the locks to -be released cannot be released, the operations before the failing -operation are guaranteed to have completed successfully, and -lock_vec returns a non-zero value. In addition, if elistp -is not NULL, it is set to point to the DB_LOCKREQ entry that was being -processed when the error occurred. -
The lock_vec function may -return -one of the following values: -
Otherwise, the lock_vec function returns a non-zero error value on failure and 0 on success. -
The lock_vec function may fail and return a non-zero error for the following conditions: -
The lock_vec function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the lock_vec function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_archive.html b/bdb/docs/api_c/log_archive.html deleted file mode 100644 index 6c9aea26b8d..00000000000 --- a/bdb/docs/api_c/log_archive.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - -
-
-log_archive- |
-
-
- |
-#include <db.h> --int -log_archive(DB_ENV *env, char *(*listp)[], - u_int32_t flags, void *(*db_malloc)(size_t)); -
The log_archive function -creates a NULL-terminated array of log or database file names and copies -a pointer to them into the user-specified memory location listp. -
By default, log_archive returns the names of all of the log files -that are no longer in use (e.g., no longer involved in active transactions), -and that may safely be archived for catastrophic recovery and then removed -from the system. If there were no file names to return, the memory location -referenced by listp will be set to NULL. -
Arrays of log file names are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_ARCH_DATA and DB_ARCH_LOG flags are mutually -exclusive. -
See the db_archive manual page for more information on database -archival procedures. -
The log_archive function is the underlying function used by the db_archive utility. -See the db_archive utility source code for an example of using log_archive -in a IEEE/ANSI Std 1003.1 (POSIX) environment. -
The log_archive function returns a non-zero error value on failure and 0 on success. -
In a threaded application (i.e., one where the environment was created -with the DB_THREAD flag specified), calling log_archive with the -DB_ARCH_DATA flag will fail, returning EINVAL. To work around this -problem, re-open the log explicitly without specifying DB_THREAD. This -restriction is expected to be removed in a future version of Berkeley DB. -
The log_archive function may fail and return a non-zero error for the following conditions: -
The log was corrupted. -
The log_archive function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_archive function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_compare.html b/bdb/docs/api_c/log_compare.html deleted file mode 100644 index c6e7743beb1..00000000000 --- a/bdb/docs/api_c/log_compare.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - -
-
-log_compare- |
-
-
- |
-#include <db.h> --int -log_compare(const DB_LSN *lsn0, const DB_LSN *lsn1); -
The log_compare function allows the caller to compare two -DB_LSN structures, -returning 0 if they are equal, 1 if lsn0 is greater than -lsn1, and -1 if lsn0 is less than lsn1. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_file.html b/bdb/docs/api_c/log_file.html deleted file mode 100644 index 434380cccb0..00000000000 --- a/bdb/docs/api_c/log_file.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-log_file- |
-
-
- |
-#include <db.h> --int -log_file(DB_ENV *env, - const DB_LSN *lsn, char *namep, size_t len); -
The log_file function maps -DB_LSN structures -to file names, -copying the name of the file containing the record named by lsn -into the memory location referenced by namep. -
The len argument is the length of the namep buffer in bytes. -If namep is too short to hold the file name, log_file will -return ENOMEM. -(Log file names are normally quite short, on the order of 10 characters.) -
This mapping of -DB_LSN structures -to files is needed for database administration. For example, a -transaction manager typically records the earliest -DB_LSN -needed for restart, and the database administrator may want to archive -log files to tape when they contain only -DB_LSN -entries before the earliest one needed for restart. -
The log_file function returns a non-zero error value on failure and 0 on success. -
The log_file function may fail and return a non-zero error for the following conditions: -
The log_file function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_file function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_flush.html b/bdb/docs/api_c/log_flush.html deleted file mode 100644 index 1315fc10670..00000000000 --- a/bdb/docs/api_c/log_flush.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
-log_flush- |
-
-
- |
-#include <db.h> --int -log_flush(DB_ENV *env, const DB_LSN *lsn); -
The log_flush function guarantees that all log records whose -DB_LSN values -are less than or equal to the lsn argument have been -written to disk. If lsn is NULL, all records in the -log are flushed. -
The log_flush function returns a non-zero error value on failure and 0 on success. -
The log_flush function may fail and return a non-zero error for the following conditions: -
The log_flush function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_flush function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_get.html b/bdb/docs/api_c/log_get.html deleted file mode 100644 index 05761e1ea30..00000000000 --- a/bdb/docs/api_c/log_get.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - -
-
-log_get- |
-
-
- |
-#include <db.h> --int -log_get(DB_ENV *env, DB_LSN *lsn, DBT *data, u_int32_t flags); -
The log_get function implements a cursor inside of the log, -retrieving records from the log according to the lsn and -flags arguments. -
The data field of the data structure is set to the record -retrieved and the size field indicates the number of bytes in the record. -See DBT for a description of other fields in the data -structure. When multiple threads are using the returned log handle -concurrently, one of the DB_DBT_MALLOC, DB_DBT_REALLOC or -DB_DBT_USERMEM flags must be specified for any DBT used -for data retrieval. -
The flags argument must be set to exactly one of the following values: -
If the log is empty, the log_get function will return DB_NOTFOUND. -
If the log is empty, the log_get function will return DB_NOTFOUND. -
If the log is empty, the log_get function will return DB_NOTFOUND. -
If the pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, log_get will return the first record in the log. -If the last log record has already been returned or the log is empty, the -log_get function will return DB_NOTFOUND. -
If the log was opened with the DB_THREAD flag set, calls to -log_get with the DB_NEXT flag set will return EINVAL. -
If the pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, -log_get will return the last record in the log. -If the first log record has already been returned or the log is empty, the -log_get function will return DB_NOTFOUND. -
If the log was opened with the DB_THREAD flag set, calls to -log_get with the DB_PREV flag set will return EINVAL. -
If the log pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, or if the log was opened with the DB_THREAD flag set, -log_get will return EINVAL. -
Otherwise, the log_get function returns a non-zero error value on failure and 0 on success. -
The log_get function may fail and return a non-zero error for the following conditions: -
The DB_FIRST flag was specified and no log files were found. -
The log_get function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_get function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_put.html b/bdb/docs/api_c/log_put.html deleted file mode 100644 index 9455296986e..00000000000 --- a/bdb/docs/api_c/log_put.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - -
-
-log_put- |
-
-
- |
-#include <db.h> --int -log_put(DB_ENV *env, - DB_LSN *lsn, const DBT *data, u_int32_t flags); -
The log_put function appends records to the log. The DB_LSN of -the put record is returned in the lsn argument. The flags -argument may be set to one of the following values: -
The caller is responsible for providing any necessary structure to -data. (For example, in a write-ahead logging protocol, the -application must understand what part of data is an operation -code, what part is redo information, and what part is undo information. -In addition, most transaction managers will store in data the -DB_LSN of the previous log record for the same transaction, to -support chaining back through the transaction's log records during -undo.) -
The log_put function returns a non-zero error value on failure and 0 on success. -
The log_flush function may fail and return a non-zero error for the following conditions: -
The record to be logged is larger than the maximum log record. -
The log_put function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_put function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_register.html b/bdb/docs/api_c/log_register.html deleted file mode 100644 index e993feabed2..00000000000 --- a/bdb/docs/api_c/log_register.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - -
-
-log_register- |
-
-
- |
-#include <db.h> --int -log_register(DB_ENV *env, DB *dbp, const char *name); -
The log_register function registers a file name with the specified Berkeley DB -environment's log manager. The log manager records all file name mappings -at each checkpoint so that a recovery process can identify the file to -which a record in the log refers. -
The dbp argument should be a reference to the DB structure being -registered. The name argument should be a file name appropriate -for opening the file in the environment, during recovery. -
The log_register function returns a non-zero error value on failure and 0 on success. -
The log_register function may fail and return a non-zero error for the following conditions: -
The log_register function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_register function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_stat.html b/bdb/docs/api_c/log_stat.html deleted file mode 100644 index 819c603d318..00000000000 --- a/bdb/docs/api_c/log_stat.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-log_stat- |
-
-
- |
-#include <db.h> --int -log_stat(DB_ENV *env, - DB_LOG_STAT **spp, void *(*db_malloc)(size_t)); -
The log_stat function -creates a statistical structure and copies a pointer to it into a -user-specified memory location. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The log region statistics are stored in a structure of type DB_LOG_STAT. -The following DB_LOG_STAT fields will be filled in: -
The log_stat function returns a non-zero error value on failure and 0 on success. -
The log_stat function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_stat function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/log_unregister.html b/bdb/docs/api_c/log_unregister.html deleted file mode 100644 index cfc1e6f2e5d..00000000000 --- a/bdb/docs/api_c/log_unregister.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-log_unregister- |
-
-
- |
-#include <db.h> --int -log_unregister(DB_ENV *env, DB *dbp); -
The log_unregister function function unregisters the file represented by -the dbp parameter from the Berkeley DB environment's log manager. -
The log_unregister function returns a non-zero error value on failure and 0 on success. -
The log_unregister function may fail and return a non-zero error for the following conditions: -
The log_unregister function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the log_unregister function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_fclose.html b/bdb/docs/api_c/memp_fclose.html deleted file mode 100644 index ae8ce3c5647..00000000000 --- a/bdb/docs/api_c/memp_fclose.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - -
-
-memp_fclose- |
-
-
- |
-#include <db.h> --int -memp_fclose(DB_MPOOLFILE *mpf); -
The memp_fclose function closes the source file indicated by the -DB_MPOOLFILE structure. Calling memp_fclose does not imply -a call to memp_fsync, i.e. no pages are written to the source -file as as a result of calling memp_fclose. -
In addition, if the file argument to memp_fopen was NULL, -any underlying files created for this DB_MPOOLFILE will be removed. -
Once memp_fclose has been called, regardless of its return, the -DB_MPOOLFILE handle may not be accessed again. -
The memp_fclose function returns a non-zero error value on failure and 0 on success. -
The memp_fclose function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_fclose function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_fget.html b/bdb/docs/api_c/memp_fget.html deleted file mode 100644 index 84b39e53ee1..00000000000 --- a/bdb/docs/api_c/memp_fget.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - -
-
-memp_fget- |
-
-
- |
-#include <db.h> --int -memp_fget(DB_MPOOLFILE *mpf, - db_pgno_t *pgnoaddr, u_int32_t flags, void **pagep); -
The memp_fget function copies a pointer to the page with the page -number specified by pgnoaddr, from the source file in the -DB_MPOOLFILE, into the memory location referenced by pagep. -If the page does not exist or cannot be retrieved, memp_fget will -fail. -
Page numbers begin at 0, i.e., the first page in the file is page number -0, not page number 1. -
The returned page is size_t type aligned. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_MPOOL_CREATE, DB_MPOOL_LAST and -DB_MPOOL_NEW flags are mutually exclusive. -
Created pages have all their bytes set to 0, unless otherwise specified -when the file was opened. -
All pages returned by memp_fget will be retained (i.e. -pinned), in the pool until a subsequent call to -memp_fput. -
The memp_fget function returns a non-zero error value on failure and 0 on success. -
The memp_fget function may fail and return a non-zero error for the following conditions: -
The DB_MPOOL_NEW flag was set and the source file was not opened for writing. -
More than one of DB_MPOOL_CREATE, DB_MPOOL_LAST and DB_MPOOL_NEW was set. -
The memp_fget function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_fget function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_fopen.html b/bdb/docs/api_c/memp_fopen.html deleted file mode 100644 index ea0250246cb..00000000000 --- a/bdb/docs/api_c/memp_fopen.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - -
-
-memp_fopen- |
-
-
- |
-#include <db.h> --int -memp_fopen(DB_ENV *env, char *file, u_int32_t flags, - int mode, size_t pagesize, DB_MPOOL_FINFO *finfop, - DB_MPOOLFILE **mpf); -
The memp_fopen function opens a file in the pool specified by the -DB_ENV env, copying the DB_MPOOLFILE pointer -representing it into the memory location referenced by mpf. -
The file argument is the name of the file to be opened. -If file is NULL, a private file is created that cannot be -shared with any other process (although it may be shared with -other threads). -
The flags and mode arguments specify how files will be opened -and/or created if they do not already exist. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by function memp_fopen -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
The pagesize argument is the size, in bytes, of the unit of transfer -between the application and the pool, although it is not necessarily the -unit of transfer between the pool and the source file. -
Files opened in the pool may be further configured based on the -finfop argument to memp_fopen (which is a pointer to a -structure of type DB_MPOOL_FINFO). No references to the finfop -structure are maintained by Berkeley DB, so it may be discarded when the -memp_fopen function returns. In order to ensure compatibility -with future releases of Berkeley DB, all fields of the DB_MPOOL_FINFO structure -that are not explicitly set should be initialized to 0 before the first -time the structure is used. Do this by declaring the structure external -or static, or by calling the C library routine bzero(3) or -memset(3). -
The fields of the DB_MPOOL_FINFO structure used by memp_fopen are -described below. If finfop is NULL or any of its fields are -set to their default value, defaults appropriate for the system are used. -
The mpool functions must be able to uniquely identify files in order that -multiple processes wanting to share a file will correctly identify it in -the pool. -
On most UNIX/POSIX systems, the fileid field will not need to be -set and the mpool functions will simply use the file's device and inode -numbers for this purpose. On Windows systems, the mpool functions use -the values returned by GetFileInformationByHandle() by default -- these -values are known to be constant between processes and over reboot in the -case of NTFS (where they are the NTFS MFT indexes). -
On other filesystems, (e.g., FAT or NFS) these default values are not -necessarily unique between processes or across system reboots. -Applications wanting to maintain a shared memory buffer pool -between processes or across system reboots, where the pool contains pages -from files stored on such filesystems, must specify a unique file -identifier to the memp_fopen call and each process opening or -registering the file must provide the same unique identifier. -
This should not be necessary for most applications. Specifically, it is -not necessary if the memory pool is not shared between processes and is -re-instantiated after each system reboot, or the application is using the -Berkeley DB access methods instead of calling the pool functions explicitly, or -the files in the memory pool are stored on filesystems where the default -values as described above are invariant between process and across system -reboots. -
The memp_fopen function returns a non-zero error value on failure and 0 on success. -
The memp_fopen function may fail and return a non-zero error for the following conditions: -
The file has already been entered into the pool, and the pagesize -value is not the same as when the file was entered into the pool, or the -length of the file is not zero or a multiple of the pagesize. -
The DB_RDONLY flag was specified for an in-memory pool. -
The memp_fopen function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_fopen function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_fput.html b/bdb/docs/api_c/memp_fput.html deleted file mode 100644 index ce382b4d034..00000000000 --- a/bdb/docs/api_c/memp_fput.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - -
-
-memp_fput- |
-
-
- |
-#include <db.h> --int -memp_fput(DB_MPOOLFILE *mpf, void *pgaddr, u_int32_t flags); -
The memp_fput function indicates that the page referenced by -pgaddr can be evicted from the pool. The pgaddr -argument must be an address previously returned by memp_fget. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_MPOOL_CLEAN and DB_MPOOL_DIRTY flags are -mutually exclusive. -
The memp_fput function returns a non-zero error value on failure and 0 on success. -
The memp_fput function may fail and return a non-zero error for the following conditions: -
The pgaddr parameter does not reference a page returned by -memp_fget. -
More than one of DB_MPOOL_CLEAN and DB_MPOOL_DIRTY flags was set. -
The memp_fput function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_fput function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_fset.html b/bdb/docs/api_c/memp_fset.html deleted file mode 100644 index 73acd322c4e..00000000000 --- a/bdb/docs/api_c/memp_fset.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-memp_fset- |
-
-
- |
-#include <db.h> --int -memp_fset(DB_MPOOLFILE *mpf, void *pgaddr, u_int32_t flags); -
The memp_fset function sets the flags associated with the page referenced -by pgaddr without unpinning it from the pool. The pgaddr -argument must be an address previously returned by memp_fget. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_MPOOL_CLEAN and DB_MPOOL_DIRTY flags are -mutually exclusive. -
The memp_fset function returns a non-zero error value on failure and 0 on success. -
The memp_fset function may fail and return a non-zero error for the following conditions: -
The memp_fset function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_fset function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_fsync.html b/bdb/docs/api_c/memp_fsync.html deleted file mode 100644 index ad429ccf390..00000000000 --- a/bdb/docs/api_c/memp_fsync.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-memp_fsync- |
-
-
- |
-#include <db.h> --int -memp_fsync(DB_MPOOLFILE *mpf); -
The memp_fsync function writes all pages associated with the -DB_MPOOLFILE, that were marked as modified using memp_fput -or memp_fset, back to the source file. If any of the modified -pages are also pinned (i.e., currently referenced by this or -another process) memp_fsync will ignore them. -
The memp_fsync function returns a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if there were pages which were -modified but which memp_fsync was unable to write immediately. -
The memp_fsync function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_fsync function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_register.html b/bdb/docs/api_c/memp_register.html deleted file mode 100644 index 7c50a89ed2b..00000000000 --- a/bdb/docs/api_c/memp_register.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - -
-
-memp_register- |
-
-
- |
-#include <db.h> --int -memp_register(DB_ENV *env, int ftype, - int (*pgin_fcn)(DB_ENV *, db_pgno_t pgno, void *pgaddr, DBT *pgcookie), - int (*pgout_fcn)(DB_ENV *, db_pgno_t pgno, void *pgaddr, DBT *pgcookie)); -
The memp_register function registers page-in and page-out -functions for files of type ftype in the specified pool. -
If the pgin_fcn function is non-NULL, it is called each time -a page is read into the memory pool from a file of type ftype, or -a page is created for a file of type ftype (see the -DB_MPOOL_CREATE flag for the memp_fget function). -
If the pgout_fcn function is non-NULL, it is called each time -a page is written to a file of type ftype. -
Both the pgin_fcn and pgout_fcn functions are called with -a reference to the current environment, the page number, a pointer to the -page being read or written, and any argument pgcookie that was -specified to the memp_fopen function when the file was opened. -The pgin_fcn and pgout_fcn functions should return 0 on -success, and an applicable non-zero errno value on failure, in -which case the shared memory pool interface routine (and, by extension, -any Berkeley DB library function) calling it will also fail, returning that -errno value. -
The purpose of the memp_register function is to support processing -when pages are entered into, or flushed from, the pool. A file type must -be specified to make it possible for unrelated threads or processes, that -are sharing a pool, to evict each other's pages from the pool. -Applications should call memp_register, during initialization, -for each type of file requiring input or output processing that will be -sharing the underlying pool. (No registry is necessary for the standard -Berkeley DB access method types, as DB->open registers them -separately.) -
If a thread or process does not call memp_register for a file -type, it is impossible for it to evict pages for any file requiring input -or output processing from the pool. For this reason, -memp_register should always be called by each application sharing -a pool for each type of file included in the pool, regardless of whether -or not the application itself uses files of that type. -
There are no standard values for ftype, pgin_fcn, -pgout_fcn and pgcookie, except that the ftype -value for a file must be a non-zero positive number, as negative numbers -are reserved for internal use by the Berkeley DB library. For this reason, -applications sharing a pool must coordinate their values amongst -themselves. -
The memp_register function returns a non-zero error value on failure and 0 on success. -
The memp_register function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_register function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_stat.html b/bdb/docs/api_c/memp_stat.html deleted file mode 100644 index 8e9d136a90b..00000000000 --- a/bdb/docs/api_c/memp_stat.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - -
-
-memp_stat- |
-
-
- |
-#include <db.h> --int -memp_stat(DB_ENV *env, DB_MPOOL_STAT **gsp, - DB_MPOOL_FSTAT *(*fsp)[], void *(*db_malloc)(size_t)); -
The memp_stat function method creates statistical structures and copies -pointers to them into user-specified memory locations. The statistics -include the number of files participating in the pool, the active pages -in the pool, and information as to how effective the cache has been. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
If gsp is non-NULL, the global statistics for the memory pool -mp are copied into the memory location it references. The -global statistics are stored in a structure of type DB_MPOOL_STAT. -
The following DB_MPOOL_STAT fields will be filled in: -
If fsp is non-NULL, a pointer to a NULL-terminated variable -length array of statistics for individual files, in the memory pool mp, -is copied into the memory location it references. If no individual files -currently exist in the memory pool, fsp will be set to NULL. -
The per-file statistics are stored in structures of type DB_MPOOL_FSTAT. -The following DB_MPOOL_FSTAT fields will be filled in for each file in -the pool, i.e., each element of the array: -
The memp_stat function returns a non-zero error value on failure and 0 on success. -
The memp_stat function may fail and return a non-zero error for the following conditions: -
The memp_stat function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_stat function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_sync.html b/bdb/docs/api_c/memp_sync.html deleted file mode 100644 index fc693d47eff..00000000000 --- a/bdb/docs/api_c/memp_sync.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-memp_sync- |
-
-
- |
-#include <db.h> --int -memp_sync(DB_ENV *env, DB_LSN *lsn); -
The memp_sync function ensures that any modified pages in the pool with -log sequence numbers less than the lsn argument are written to -disk. If lsn is NULL all modified pages in the pool are -flushed. -
The primary purpose of the memp_sync function is to enable a -transaction manager to ensure, as part of a checkpoint, that all pages -modified by a certain time have been written to disk. Pages in the pool -that cannot be written back to disk immediately (e.g., that are currently -pinned) are written to disk as soon as it is possible to do so. The -expected behavior of the Berkeley DB or other transaction subsystem is to call -the memp_sync function and then, if the return indicates that some -pages could not be written immediately, to wait briefly and retry again -with the same log sequence number until the memp_sync function -returns that all pages have been written. -
To support the memp_sync functionality, it is necessary that the -pool functions know the location of the log sequence number on the page -for each file type. This location should be specified when the file is -opened using the memp_fopen function. It is not required that -the log sequence number be aligned on the page in any way. -
The memp_sync function returns a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if there were pages which need to be -written but which memp_sync was unable to write immediately. -In addition, if memp_sync returns success, the value of -lsn will be overwritten with the largest log sequence number -from any page which was written by memp_sync to satisfy this -request. -
The memp_sync function may fail and return a non-zero error for the following conditions: -
The memp_sync function was called without logging having been -initialized in the environment. -
The memp_sync function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_sync function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/memp_trickle.html b/bdb/docs/api_c/memp_trickle.html deleted file mode 100644 index d7cfd723020..00000000000 --- a/bdb/docs/api_c/memp_trickle.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-memp_trickle- |
-
-
- |
-#include <db.h> --int -memp_trickle(DB_ENV *env, int pct, int *nwrotep); -
The memp_trickle function ensures that at least pct percent of -the pages in the shared memory pool are clean by writing dirty pages to -their backing files. -If the nwrotep argument is non-NULL, the number of pages that -were written to reach the correct percentage is returned in the memory -location it references. -
The purpose of the memp_trickle function is to enable a memory -pool manager to ensure that a page is always available for reading in new -information without having to wait for a write. -
The memp_trickle function returns a non-zero error value on failure and 0 on success. -
The memp_trickle function may fail and return a non-zero error for the following conditions: -
The memp_trickle function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the memp_trickle function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/pindex.src b/bdb/docs/api_c/pindex.src deleted file mode 100644 index 1818c50a6d1..00000000000 --- a/bdb/docs/api_c/pindex.src +++ /dev/null @@ -1,301 +0,0 @@ -__APIREL__/api_c/db_create.html#2 @db_create -__APIREL__/api_c/db_create.html#DB_XA_CREATE db_create@DB_XA_CREATE -__APIREL__/api_c/db_err.html#2 @DBENV-__GT__err -__APIREL__/api_c/db_lsn.html#2 @DB_LSN -__APIREL__/api_c/db_set_errfile.html#2 @DB-__GT__set_errfile -__APIREL__/api_c/db_set_malloc.html#2 @DB-__GT__set_malloc -__APIREL__/api_c/db_set_paniccall.html#2 @DB-__GT__set_paniccall -__APIREL__/api_c/db_set_realloc.html#2 @DB-__GT__set_realloc -__APIREL__/api_c/dbm.html#2 @dbm/ndbm -__APIREL__/api_c/dbt.html#2 @key/data pairs -__APIREL__/api_c/dbt.html#data DBT@data -__APIREL__/api_c/dbt.html#size DBT@size -__APIREL__/api_c/dbt.html#ulen DBT@ulen -__APIREL__/api_c/dbt.html#dlen DBT@dlen -__APIREL__/api_c/dbt.html#doff DBT@doff -__APIREL__/api_c/dbt.html#DB_DBT_MALLOC DBT@DB_DBT_MALLOC -__APIREL__/api_c/dbt.html#DB_DBT_REALLOC DBT@DB_DBT_REALLOC -__APIREL__/api_c/dbt.html#DB_DBT_USERMEM DBT@DB_DBT_USERMEM -__APIREL__/api_c/dbt.html#DB_DBT_PARTIAL DBT@DB_DBT_PARTIAL -__APIREL__/api_c/dbt.html#3 retrieved key/data @permanence -__APIREL__/api_c/dbt.html#4 retrieved @key/data permanence -__APIREL__/api_c/dbt.html#5 data @alignment -__APIREL__/api_c/dbt.html#6 logical @record number format -__APIREL__/api_c/env_create.html#2 @db_env_create -__APIREL__/api_c/env_create.html#DB_CLIENT db_env_create@DB_CLIENT -__APIREL__/api_c/env_set_errfile.html#2 @DBENV-__GT__set_errfile -__APIREL__/api_c/env_set_paniccall.html#2 @DBENV-__GT__set_paniccall -__APIREL__/api_c/hsearch.html#2 @hsearch -__APIREL__/api_c/set_func_close.html#2 @db_env_set_func_close -__APIREL__/api_c/set_func_dirfree.html#2 @db_env_set_func_dirfree -__APIREL__/api_c/set_func_dirlist.html#2 @db_env_set_func_dirlist -__APIREL__/api_c/set_func_exists.html#2 @db_env_set_func_exists -__APIREL__/api_c/set_func_free.html#2 @db_env_set_func_free -__APIREL__/api_c/set_func_fsync.html#2 @db_env_set_func_fsync -__APIREL__/api_c/set_func_ioinfo.html#2 @db_env_set_func_ioinfo -__APIREL__/api_c/set_func_malloc.html#2 @db_env_set_func_malloc -__APIREL__/api_c/set_func_map.html#2 @db_env_set_func_map -__APIREL__/api_c/set_func_open.html#2 @db_env_set_func_open -__APIREL__/api_c/set_func_read.html#2 @db_env_set_func_read -__APIREL__/api_c/set_func_realloc.html#2 @db_env_set_func_realloc -__APIREL__/api_c/set_func_rename.html#2 @db_env_set_func_rename -__APIREL__/api_c/set_func_seek.html#2 @db_env_set_func_seek -__APIREL__/api_c/set_func_sleep.html#2 @db_env_set_func_sleep -__APIREL__/api_c/set_func_unlink.html#2 @db_env_set_func_unlink -__APIREL__/api_c/set_func_unmap.html#2 @db_env_set_func_unmap -__APIREL__/api_c/set_func_write.html#2 @db_env_set_func_write -__APIREL__/api_c/set_func_yield.html#2 @db_env_set_func_yield -__APIREL__/api_c/db_close.html#2 @DB-__GT__close -__APIREL__/api_c/db_close.html#DB_NOSYNC DB-__GT__close@DB_NOSYNC -__APIREL__/api_c/db_close.html#3 DB-__GT__close @DB_INCOMPLETE -__APIREL__/api_c/db_cursor.html#2 @DB-__GT__cursor -__APIREL__/api_c/db_cursor.html#DB_WRITECURSOR DB-__GT__cursor@DB_WRITECURSOR -__APIREL__/api_c/db_del.html#2 @DB-__GT__del -__APIREL__/api_c/db_fd.html#2 @DB-__GT__fd -__APIREL__/api_c/db_get.html#2 @DB-__GT__get -__APIREL__/api_c/db_get.html#DB_CONSUME DB-__GT__get@DB_CONSUME -__APIREL__/api_c/db_get.html#DB_CONSUME_WAIT DB-__GT__get@DB_CONSUME_WAIT -__APIREL__/api_c/db_get.html#DB_GET_BOTH DB-__GT__get@DB_GET_BOTH -__APIREL__/api_c/db_get.html#DB_SET_RECNO DB-__GT__get@DB_SET_RECNO -__APIREL__/api_c/db_get.html#DB_RMW DB-__GT__get@DB_RMW -__APIREL__/api_c/db_get_byteswapped.html#2 @DB-__GT__get_byteswapped -__APIREL__/api_c/db_get_type.html#2 @DB-__GT__get_type -__APIREL__/api_c/db_join.html#2 @DB-__GT__join -__APIREL__/api_c/db_join.html#DB_JOIN_NOSORT DB-__GT__join@DB_JOIN_NOSORT -__APIREL__/api_c/db_join.html#DB_JOIN_ITEM DB-__GT__join@DB_JOIN_ITEM -__APIREL__/api_c/db_join.html#DB_RMW DB-__GT__join@DB_RMW -__APIREL__/api_c/db_key_range.html#2 @DB-__GT__key_range -__APIREL__/api_c/db_open.html#2 @DB-__GT__open -__APIREL__/api_c/db_open.html#DB_CREATE DB-__GT__open@DB_CREATE -__APIREL__/api_c/db_open.html#DB_EXCL DB-__GT__open@DB_EXCL -__APIREL__/api_c/db_open.html#DB_NOMMAP DB-__GT__open@DB_NOMMAP -__APIREL__/api_c/db_open.html#DB_RDONLY DB-__GT__open@DB_RDONLY -__APIREL__/api_c/db_open.html#DB_THREAD DB-__GT__open@DB_THREAD -__APIREL__/api_c/db_open.html#DB_TRUNCATE DB-__GT__open@DB_TRUNCATE -__APIREL__/api_c/db_open.html#DB_OLD_VERSION DB-__GT__open@DB_OLD_VERSION -__APIREL__/api_c/db_put.html#2 @DB-__GT__put -__APIREL__/api_c/db_put.html#DB_APPEND DB-__GT__put@DB_APPEND -__APIREL__/api_c/db_put.html#DB_NODUPDATA DB-__GT__put@DB_NODUPDATA -__APIREL__/api_c/db_put.html#DB_NOOVERWRITE DB-__GT__put@DB_NOOVERWRITE -__APIREL__/api_c/db_remove.html#2 @DB-__GT__remove -__APIREL__/api_c/db_rename.html#2 @DB-__GT__rename -__APIREL__/api_c/db_set_append_recno.html#2 @DB-__GT__set_append_recno -__APIREL__/api_c/db_set_bt_compare.html#2 @DB-__GT__set_bt_compare -__APIREL__/api_c/db_set_bt_minkey.html#2 @DB-__GT__set_bt_minkey -__APIREL__/api_c/db_set_bt_prefix.html#2 @DB-__GT__set_bt_prefix -__APIREL__/api_c/db_set_cachesize.html#2 @DB-__GT__set_cachesize -__APIREL__/api_c/db_set_dup_compare.html#2 @DB-__GT__set_dup_compare -__APIREL__/api_c/db_set_errcall.html#2 @DB-__GT__set_errcall -__APIREL__/api_c/db_set_errpfx.html#2 @DB-__GT__set_errpfx -__APIREL__/api_c/db_set_feedback.html#2 @DB-__GT__set_feedback -__APIREL__/api_c/db_set_feedback.html#DB_UPGRADE DB-__GT__set_feedback@DB_UPGRADE -__APIREL__/api_c/db_set_feedback.html#DB_VERIFY DB-__GT__set_feedback@DB_VERIFY -__APIREL__/api_c/db_set_flags.html#2 @DB-__GT__set_flags -__APIREL__/api_c/db_set_flags.html#DB_DUP DB-__GT__set_flags@DB_DUP -__APIREL__/api_c/db_set_flags.html#DB_DUPSORT DB-__GT__set_flags@DB_DUPSORT -__APIREL__/api_c/db_set_flags.html#DB_RECNUM DB-__GT__set_flags@DB_RECNUM -__APIREL__/api_c/db_set_flags.html#DB_REVSPLITOFF DB-__GT__set_flags@DB_REVSPLITOFF -__APIREL__/api_c/db_set_flags.html#DB_DUP DB-__GT__set_flags@DB_DUP -__APIREL__/api_c/db_set_flags.html#DB_DUPSORT DB-__GT__set_flags@DB_DUPSORT -__APIREL__/api_c/db_set_flags.html#DB_RENUMBER DB-__GT__set_flags@DB_RENUMBER -__APIREL__/api_c/db_set_flags.html#DB_SNAPSHOT DB-__GT__set_flags@DB_SNAPSHOT -__APIREL__/api_c/db_set_h_ffactor.html#2 @DB-__GT__set_h_ffactor -__APIREL__/api_c/db_set_h_hash.html#2 @DB-__GT__set_h_hash -__APIREL__/api_c/db_set_h_nelem.html#2 @DB-__GT__set_h_nelem -__APIREL__/api_c/db_set_lorder.html#2 @DB-__GT__set_lorder -__APIREL__/api_c/db_set_pagesize.html#2 @DB-__GT__set_pagesize -__APIREL__/api_c/db_set_q_extentsize.html#2 @DB-__GT__set_q_extentsize -__APIREL__/api_c/db_set_re_delim.html#2 @DB-__GT__set_re_delim -__APIREL__/api_c/db_set_re_len.html#2 @DB-__GT__set_re_len -__APIREL__/api_c/db_set_re_pad.html#2 @DB-__GT__set_re_pad -__APIREL__/api_c/db_set_re_source.html#2 @DB-__GT__set_re_source -__APIREL__/api_c/db_stat.html#2 @DB-__GT__stat -__APIREL__/api_c/db_stat.html#DB_CACHED_COUNTS DB-__GT__stat@DB_CACHED_COUNTS -__APIREL__/api_c/db_stat.html#DB_RECORDCOUNT DB-__GT__stat@DB_RECORDCOUNT -__APIREL__/api_c/db_sync.html#2 @DB-__GT__sync -__APIREL__/api_c/db_upgrade.html#2 @DB-__GT__upgrade -__APIREL__/api_c/db_upgrade.html#DB_DUPSORT DB-__GT__upgrade@DB_DUPSORT -__APIREL__/api_c/db_upgrade.html#DB_OLD_VERSION DB-__GT__upgrade@DB_OLD_VERSION -__APIREL__/api_c/db_verify.html#2 @DB-__GT__verify -__APIREL__/api_c/db_verify.html#DB_SALVAGE DB-__GT__verify@DB_SALVAGE -__APIREL__/api_c/db_verify.html#DB_AGGRESSIVE DB-__GT__verify@DB_AGGRESSIVE -__APIREL__/api_c/db_verify.html#DB_NOORDERCHK DB-__GT__verify@DB_NOORDERCHK -__APIREL__/api_c/db_verify.html#DB_ORDERCHKONLY DB-__GT__verify@DB_ORDERCHKONLY -__APIREL__/api_c/dbc_close.html#2 @DBcursor-__GT__c_close -__APIREL__/api_c/dbc_count.html#2 @DBcursor-__GT__c_count -__APIREL__/api_c/dbc_del.html#2 @DBcursor-__GT__c_del -__APIREL__/api_c/dbc_dup.html#2 @DBcursor-__GT__c_dup -__APIREL__/api_c/dbc_dup.html#DB_POSITION DBcursor-__GT__c_dup@DB_POSITION -__APIREL__/api_c/dbc_get.html#2 @DBcursor-__GT__c_get -__APIREL__/api_c/dbc_get.html#DB_CURRENT DBcursor-__GT__c_get@DB_CURRENT -__APIREL__/api_c/dbc_get.html#DB_FIRST DBcursor-__GT__c_get@DB_FIRST -__APIREL__/api_c/dbc_get.html#DB_LAST DBcursor-__GT__c_get@DB_LAST -__APIREL__/api_c/dbc_get.html#DB_GET_BOTH DBcursor-__GT__c_get@DB_GET_BOTH -__APIREL__/api_c/dbc_get.html#DB_GET_RECNO DBcursor-__GT__c_get@DB_GET_RECNO -__APIREL__/api_c/dbc_get.html#DB_JOIN_ITEM DBcursor-__GT__c_get@DB_JOIN_ITEM -__APIREL__/api_c/dbc_get.html#DB_NEXT DBcursor-__GT__c_get@DB_NEXT -__APIREL__/api_c/dbc_get.html#DB_PREV DBcursor-__GT__c_get@DB_PREV -__APIREL__/api_c/dbc_get.html#DB_NEXT_DUP DBcursor-__GT__c_get@DB_NEXT_DUP -__APIREL__/api_c/dbc_get.html#DB_NEXT_NODUP DBcursor-__GT__c_get@DB_NEXT_NODUP -__APIREL__/api_c/dbc_get.html#DB_PREV_NODUP DBcursor-__GT__c_get@DB_PREV_NODUP -__APIREL__/api_c/dbc_get.html#DB_SET DBcursor-__GT__c_get@DB_SET -__APIREL__/api_c/dbc_get.html#DB_SET_RANGE DBcursor-__GT__c_get@DB_SET_RANGE -__APIREL__/api_c/dbc_get.html#DB_SET_RECNO DBcursor-__GT__c_get@DB_SET_RECNO -__APIREL__/api_c/dbc_get.html#DB_RMW DBcursor-__GT__c_get@DB_RMW -__APIREL__/api_c/dbc_put.html#2 @DBcursor-__GT__c_put -__APIREL__/api_c/dbc_put.html#DB_AFTER DBcursor-__GT__c_put@DB_AFTER -__APIREL__/api_c/dbc_put.html#DB_BEFORE DBcursor-__GT__c_put@DB_BEFORE -__APIREL__/api_c/dbc_put.html#DB_CURRENT DBcursor-__GT__c_put@DB_CURRENT -__APIREL__/api_c/dbc_put.html#DB_KEYFIRST DBcursor-__GT__c_put@DB_KEYFIRST -__APIREL__/api_c/dbc_put.html#DB_KEYLAST DBcursor-__GT__c_put@DB_KEYLAST -__APIREL__/api_c/dbc_put.html#DB_NODUPDATA DBcursor-__GT__c_put@DB_NODUPDATA -__APIREL__/api_c/env_close.html#2 @DBENV-__GT__close -__APIREL__/api_c/env_open.html#2 @DBENV-__GT__open -__APIREL__/api_c/env_open.html#DB_JOINENV DBENV-__GT__open@DB_JOINENV -__APIREL__/api_c/env_open.html#DB_INIT_CDB DBENV-__GT__open@DB_INIT_CDB -__APIREL__/api_c/env_open.html#DB_INIT_LOCK DBENV-__GT__open@DB_INIT_LOCK -__APIREL__/api_c/env_open.html#DB_INIT_LOG DBENV-__GT__open@DB_INIT_LOG -__APIREL__/api_c/env_open.html#DB_INIT_MPOOL DBENV-__GT__open@DB_INIT_MPOOL -__APIREL__/api_c/env_open.html#DB_INIT_TXN DBENV-__GT__open@DB_INIT_TXN -__APIREL__/api_c/env_open.html#DB_RECOVER DBENV-__GT__open@DB_RECOVER -__APIREL__/api_c/env_open.html#DB_RECOVER_FATAL DBENV-__GT__open@DB_RECOVER_FATAL -__APIREL__/api_c/env_open.html#DB_USE_ENVIRON DBENV-__GT__open@DB_USE_ENVIRON -__APIREL__/api_c/env_open.html#DB_USE_ENVIRON_ROOT DBENV-__GT__open@DB_USE_ENVIRON_ROOT -__APIREL__/api_c/env_open.html#DB_CREATE DBENV-__GT__open@DB_CREATE -__APIREL__/api_c/env_open.html#DB_LOCKDOWN DBENV-__GT__open@DB_LOCKDOWN -__APIREL__/api_c/env_open.html#DB_PRIVATE DBENV-__GT__open@DB_PRIVATE -__APIREL__/api_c/env_open.html#DB_SYSTEM_MEM DBENV-__GT__open@DB_SYSTEM_MEM -__APIREL__/api_c/env_open.html#DB_THREAD DBENV-__GT__open@DB_THREAD -__APIREL__/api_c/env_remove.html#2 @DBENV-__GT__remove -__APIREL__/api_c/env_remove.html#DB_FORCE DBENV-__GT__remove@DB_FORCE -__APIREL__/api_c/env_remove.html#DB_USE_ENVIRON DBENV-__GT__remove@DB_USE_ENVIRON -__APIREL__/api_c/env_remove.html#DB_USE_ENVIRON_ROOT DBENV-__GT__remove@DB_USE_ENVIRON_ROOT -__APIREL__/api_c/env_set_cachesize.html#2 @DBENV-__GT__set_cachesize -__APIREL__/api_c/env_set_data_dir.html#2 @DBENV-__GT__set_data_dir -__APIREL__/api_c/env_set_errcall.html#2 @DBENV-__GT__set_errcall -__APIREL__/api_c/env_set_errpfx.html#2 @DBENV-__GT__set_errpfx -__APIREL__/api_c/env_set_feedback.html#2 @DBENV-__GT__set_feedback -__APIREL__/api_c/env_set_feedback.html#DB_RECOVER DBENV-__GT__set_feedback@DB_RECOVER -__APIREL__/api_c/env_set_flags.html#2 @DBENV-__GT__set_flags -__APIREL__/api_c/env_set_flags.html#DB_CDB_ALLDB DBENV-__GT__set_flags@DB_CDB_ALLDB -__APIREL__/api_c/env_set_flags.html#DB_NOMMAP DBENV-__GT__set_flags@DB_NOMMAP -__APIREL__/api_c/env_set_flags.html#DB_TXN_NOSYNC DBENV-__GT__set_flags@DB_TXN_NOSYNC -__APIREL__/api_c/env_set_lg_bsize.html#2 @DBENV-__GT__set_lg_bsize -__APIREL__/api_c/env_set_lg_dir.html#2 @DBENV-__GT__set_lg_dir -__APIREL__/api_c/env_set_lg_max.html#2 @DBENV-__GT__set_lg_max -__APIREL__/api_c/env_set_lk_conflicts.html#2 @DBENV-__GT__set_lk_conflicts -__APIREL__/api_c/env_set_lk_detect.html#2 @DBENV-__GT__set_lk_detect -__APIREL__/api_c/env_set_lk_detect.html#DB_LOCK_DEFAULT DBENV-__GT__set_lk_detect@DB_LOCK_DEFAULT -__APIREL__/api_c/env_set_lk_detect.html#DB_LOCK_OLDEST DBENV-__GT__set_lk_detect@DB_LOCK_OLDEST -__APIREL__/api_c/env_set_lk_detect.html#DB_LOCK_RANDOM DBENV-__GT__set_lk_detect@DB_LOCK_RANDOM -__APIREL__/api_c/env_set_lk_detect.html#DB_LOCK_YOUNGEST DBENV-__GT__set_lk_detect@DB_LOCK_YOUNGEST -__APIREL__/api_c/env_set_lk_max.html#2 @DBENV-__GT__set_lk_max -__APIREL__/api_c/env_set_lk_max_locks.html#2 @DBENV-__GT__set_lk_max_locks -__APIREL__/api_c/env_set_lk_max_lockers.html#2 @DBENV-__GT__set_lk_max_lockers -__APIREL__/api_c/env_set_lk_max_objects.html#2 @DBENV-__GT__set_lk_max_objects -__APIREL__/api_c/env_set_mp_mmapsize.html#2 @DBENV-__GT__set_mp_mmapsize -__APIREL__/api_c/env_set_mutexlocks.html#2 @DBENV-__GT__set_mutexlocks -__APIREL__/api_c/env_set_pageyield.html#2 @db_env_set_pageyield -__APIREL__/api_c/env_set_panicstate.html#2 @db_env_set_panicstate -__APIREL__/api_c/env_set_rec_init.html#2 @DBENV-__GT__set_recovery_init -__APIREL__/api_c/env_set_region_init.html#2 @db_env_set_region_init -__APIREL__/api_c/env_set_server.html#2 @DBENV-__GT__set_server -__APIREL__/api_c/env_set_server.html#DB_NOSERVER DBENV-__GT__set_server@DB_NOSERVER -__APIREL__/api_c/env_set_server.html#DB_NOSERVER_ID DBENV-__GT__set_server@DB_NOSERVER_ID -__APIREL__/api_c/env_set_shm_key.html#2 @DBENV-__GT__set_shm_key -__APIREL__/api_c/env_set_tas_spins.html#2 @db_env_set_tas_spins -__APIREL__/api_c/env_set_tmp_dir.html#2 @DBENV-__GT__set_tmp_dir -__APIREL__/api_c/env_set_tx_max.html#2 @DBENV-__GT__set_tx_max -__APIREL__/api_c/env_set_tx_recover.html#2 @DBENV-__GT__set_tx_recover -__APIREL__/api_c/env_set_tx_recover.html#DB_TXN_BACKWARD_ROLL DBENV-__GT__set_tx_recover@DB_TXN_BACKWARD_ROLL -__APIREL__/api_c/env_set_tx_recover.html#DB_TXN_FORWARD_ROLL DBENV-__GT__set_tx_recover@DB_TXN_FORWARD_ROLL -__APIREL__/api_c/env_set_tx_recover.html#DB_TXN_ABORT DBENV-__GT__set_tx_recover@DB_TXN_ABORT -__APIREL__/api_c/env_set_tx_timestamp.html#2 @DBENV-__GT__set_tx_timestamp -__APIREL__/api_c/env_set_verbose.html#2 @DBENV-__GT__set_verbose -__APIREL__/api_c/env_set_verbose.html#DB_VERB_CHKPOINT DBENV-__GT__set_verbose@DB_VERB_CHKPOINT -__APIREL__/api_c/env_set_verbose.html#DB_VERB_DEADLOCK DBENV-__GT__set_verbose@DB_VERB_DEADLOCK -__APIREL__/api_c/env_set_verbose.html#DB_VERB_RECOVERY DBENV-__GT__set_verbose@DB_VERB_RECOVERY -__APIREL__/api_c/env_set_verbose.html#DB_VERB_WAITSFOR DBENV-__GT__set_verbose@DB_VERB_WAITSFOR -__APIREL__/api_c/env_strerror.html#2 @db_strerror -__APIREL__/api_c/env_version.html#2 @db_version -__APIREL__/api_c/lock_detect.html#2 @lock_detect -__APIREL__/api_c/lock_detect.html#DB_LOCK_CONFLICT lock_detect@DB_LOCK_CONFLICT -__APIREL__/api_c/lock_get.html#2 @lock_get -__APIREL__/api_c/lock_get.html#DB_LOCK_NOWAIT lock_get@DB_LOCK_NOWAIT -__APIREL__/api_c/lock_get.html#DB_LOCK_NOTGRANTED lock_get@DB_LOCK_NOTGRANTED -__APIREL__/api_c/lock_id.html#2 @lock_id -__APIREL__/api_c/lock_put.html#2 @lock_put -__APIREL__/api_c/lock_stat.html#2 @lock_stat -__APIREL__/api_c/lock_vec.html#2 @lock_vec -__APIREL__/api_c/lock_vec.html#DB_LOCK_NOWAIT lock_vec@DB_LOCK_NOWAIT -__APIREL__/api_c/lock_vec.html#op lock_vec@op -__APIREL__/api_c/lock_vec.html#DB_LOCK_GET lock_vec@DB_LOCK_GET -__APIREL__/api_c/lock_vec.html#DB_LOCK_PUT lock_vec@DB_LOCK_PUT -__APIREL__/api_c/lock_vec.html#DB_LOCK_PUT_ALL lock_vec@DB_LOCK_PUT_ALL -__APIREL__/api_c/lock_vec.html#DB_LOCK_PUT_OBJ lock_vec@DB_LOCK_PUT_OBJ -__APIREL__/api_c/lock_vec.html#obj lock_vec@obj -__APIREL__/api_c/lock_vec.html#mode lock_vec@mode -__APIREL__/api_c/lock_vec.html#lock lock_vec@lock -__APIREL__/api_c/lock_vec.html#DB_LOCK_NOTGRANTED lock_vec@DB_LOCK_NOTGRANTED -__APIREL__/api_c/log_archive.html#2 @log_archive -__APIREL__/api_c/log_archive.html#DB_ARCH_ABS log_archive@DB_ARCH_ABS -__APIREL__/api_c/log_archive.html#DB_ARCH_DATA log_archive@DB_ARCH_DATA -__APIREL__/api_c/log_archive.html#DB_ARCH_LOG log_archive@DB_ARCH_LOG -__APIREL__/api_c/log_compare.html#2 @log_compare -__APIREL__/api_c/log_file.html#2 @log_file -__APIREL__/api_c/log_flush.html#2 @log_flush -__APIREL__/api_c/log_get.html#2 @log_get -__APIREL__/api_c/log_get.html#DB_CHECKPOINT log_get@DB_CHECKPOINT -__APIREL__/api_c/log_get.html#DB_FIRST log_get@DB_FIRST -__APIREL__/api_c/log_get.html#DB_LAST log_get@DB_LAST -__APIREL__/api_c/log_get.html#DB_NEXT log_get@DB_NEXT -__APIREL__/api_c/log_get.html#DB_PREV log_get@DB_PREV -__APIREL__/api_c/log_get.html#DB_CURRENT log_get@DB_CURRENT -__APIREL__/api_c/log_get.html#DB_SET log_get@DB_SET -__APIREL__/api_c/log_put.html#2 @log_put -__APIREL__/api_c/log_put.html#DB_CHECKPOINT log_put@DB_CHECKPOINT -__APIREL__/api_c/log_put.html#DB_CURLSN log_put@DB_CURLSN -__APIREL__/api_c/log_put.html#DB_FLUSH log_put@DB_FLUSH -__APIREL__/api_c/log_register.html#2 @log_register -__APIREL__/api_c/log_stat.html#2 @log_stat -__APIREL__/api_c/log_unregister.html#2 @log_unregister -__APIREL__/api_c/memp_fclose.html#2 @memp_fclose -__APIREL__/api_c/memp_fget.html#2 @memp_fget -__APIREL__/api_c/memp_fget.html#DB_MPOOL_CREATE memp_fget@DB_MPOOL_CREATE -__APIREL__/api_c/memp_fget.html#DB_MPOOL_LAST memp_fget@DB_MPOOL_LAST -__APIREL__/api_c/memp_fget.html#DB_MPOOL_NEW memp_fget@DB_MPOOL_NEW -__APIREL__/api_c/memp_fopen.html#2 @memp_fopen -__APIREL__/api_c/memp_fopen.html#DB_CREATE memp_fopen@DB_CREATE -__APIREL__/api_c/memp_fopen.html#DB_NOMMAP memp_fopen@DB_NOMMAP -__APIREL__/api_c/memp_fopen.html#DB_RDONLY memp_fopen@DB_RDONLY -__APIREL__/api_c/memp_fopen.html#ftype memp_fopen@ftype -__APIREL__/api_c/memp_fopen.html#pgcookie memp_fopen@pgcookie -__APIREL__/api_c/memp_fopen.html#fileid memp_fopen@fileid -__APIREL__/api_c/memp_fopen.html#lsn_offset memp_fopen@lsn_offset -__APIREL__/api_c/memp_fopen.html#clear_len memp_fopen@clear_len -__APIREL__/api_c/memp_fput.html#2 @memp_fput -__APIREL__/api_c/memp_fput.html#DB_MPOOL_CLEAN memp_fput@DB_MPOOL_CLEAN -__APIREL__/api_c/memp_fput.html#DB_MPOOL_DIRTY memp_fput@DB_MPOOL_DIRTY -__APIREL__/api_c/memp_fput.html#DB_MPOOL_DISCARD memp_fput@DB_MPOOL_DISCARD -__APIREL__/api_c/memp_fset.html#2 @memp_fset -__APIREL__/api_c/memp_fset.html#DB_MPOOL_CLEAN memp_fset@DB_MPOOL_CLEAN -__APIREL__/api_c/memp_fset.html#DB_MPOOL_DIRTY memp_fset@DB_MPOOL_DIRTY -__APIREL__/api_c/memp_fset.html#DB_MPOOL_DISCARD memp_fset@DB_MPOOL_DISCARD -__APIREL__/api_c/memp_fsync.html#2 @memp_fsync -__APIREL__/api_c/memp_register.html#2 @memp_register -__APIREL__/api_c/memp_stat.html#2 @memp_stat -__APIREL__/api_c/memp_sync.html#2 @memp_sync -__APIREL__/api_c/memp_trickle.html#2 @memp_trickle -__APIREL__/api_c/txn_abort.html#2 @txn_abort -__APIREL__/api_c/txn_begin.html#2 @txn_begin -__APIREL__/api_c/txn_begin.html#DB_TXN_NOSYNC txn_begin@DB_TXN_NOSYNC -__APIREL__/api_c/txn_begin.html#DB_TXN_NOWAIT txn_begin@DB_TXN_NOWAIT -__APIREL__/api_c/txn_begin.html#DB_TXN_SYNC txn_begin@DB_TXN_SYNC -__APIREL__/api_c/txn_checkpoint.html#2 @txn_checkpoint -__APIREL__/api_c/txn_checkpoint.html#DB_FORCE txn_checkpoint@DB_FORCE -__APIREL__/api_c/txn_commit.html#2 @txn_commit -__APIREL__/api_c/txn_commit.html#DB_TXN_NOSYNC txn_commit@DB_TXN_NOSYNC -__APIREL__/api_c/txn_commit.html#DB_TXN_SYNC txn_commit@DB_TXN_SYNC -__APIREL__/api_c/txn_id.html#2 @txn_id -__APIREL__/api_c/txn_prepare.html#2 @txn_prepare -__APIREL__/api_c/txn_stat.html#2 @txn_stat diff --git a/bdb/docs/api_c/set_func_close.html b/bdb/docs/api_c/set_func_close.html deleted file mode 100644 index 0d4af0aef66..00000000000 --- a/bdb/docs/api_c/set_func_close.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-db_env_set_func_close- |
-
-
- |
-#include <db.h> --int -db_env_set_func_close(int (*func_close)(int fd)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) close function -with func_close, which must conform to the standard interface. -
The db_env_set_func_close interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_close interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_close function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_dirfree.html b/bdb/docs/api_c/set_func_dirfree.html deleted file mode 100644 index 249f69cc676..00000000000 --- a/bdb/docs/api_c/set_func_dirfree.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-db_env_set_func_dirfree- |
-
-
- |
-#include <db.h> --int -db_env_set_func_dirfree(void (*func_dirfree)(char **namesp, int cnt)); -
The Berkeley DB library requires the ability to return any memory allocated as part -of the routine which reads through a directory and creates a list of files -that that the directory contains (see db_env_set_func_dirlist). -The func_dirfree argument must conform to the following interface: -
-int dirfree(char **namesp, int cnt);
The namesp and cnt arguments are the same values as were -returned by the db_env_set_func_dirlist function. -
The func_dirfree function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_dirfree interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_dirfree interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_dirfree interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The db_env_set_func_dirfree function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_dirlist.html b/bdb/docs/api_c/set_func_dirlist.html deleted file mode 100644 index 5025912e5d9..00000000000 --- a/bdb/docs/api_c/set_func_dirlist.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - -
-
-db_env_set_func_dirlist- |
-
-
- |
-#include <db.h> --int -db_env_set_func_dirlist( - int (*func_dirlist)(const char *dir, char ***namesp, int *cntp)); -
The Berkeley DB library requires the ability to read through a directory and -create a list of files that that the directory contains. The -func_dirlist argument must conform to the following interface: -
-int dirlist(const char *dir, char ***namesp, int *cntp);
The dir argument is the name of the directory to be searched. -The function must return a pointer to an array of nul-terminated file -names in the memory location referenced by the argument namesp, -and a count of the number of elements in the array in the memory location -referenced by cntp. -
The func_dirlist function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_dirlist interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_dirlist interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_dirlist interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The db_env_set_func_dirlist function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_exists.html b/bdb/docs/api_c/set_func_exists.html deleted file mode 100644 index 0b38b1e2203..00000000000 --- a/bdb/docs/api_c/set_func_exists.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-db_env_set_func_exists- |
-
-
- |
-#include <db.h> --int -db_env_set_func_exists(int (*func_exists)(const char *path, int *isdirp)); -
The Berkeley DB library requires the ability to determine if a file exists, and -optionally, if it is a file of type directory. The func argument -must conform to the following interface: -
-int exists(const char *path, int *isdirp);
The path argument is the pathname of the file to be checked. -
If the isdirp argument is non-NULL, it must be set to non-0 if -path is a directory, and 0 if path is not a directory. -
The func_exists function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_exists interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_exists interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_exists interface may only be used to configure Berkeley DB before -the DBENV->open interface is called. -
The db_env_set_func_exists function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_free.html b/bdb/docs/api_c/set_func_free.html deleted file mode 100644 index 8b7b1afa60c..00000000000 --- a/bdb/docs/api_c/set_func_free.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-db_env_set_func_free- |
-
-
- |
-#include <db.h> --int -db_env_set_func_free(void (*func_free)(void *ptr)); -
Replace Berkeley DB calls to the ANSI C X3.159-1989 (ANSI C) standard -free function with func_free, which must conform to -the standard interface. -
The db_env_set_func_free interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_free interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_free function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_fsync.html b/bdb/docs/api_c/set_func_fsync.html deleted file mode 100644 index f73956108b2..00000000000 --- a/bdb/docs/api_c/set_func_fsync.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-db_env_set_func_fsync- |
-
-
- |
-#include <db.h> --int -db_env_set_func_fsync(int (*func_fsync)(int fd)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) fsync function -with func_fsync, which must conform to the standard interface. -
The db_env_set_func_fsync interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_fsync interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_fsync function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_ioinfo.html b/bdb/docs/api_c/set_func_ioinfo.html deleted file mode 100644 index 3a0143e57ea..00000000000 --- a/bdb/docs/api_c/set_func_ioinfo.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-db_env_set_func_ioinfo- |
-
-
- |
-#include <db.h> --int -db_env_set_func_ioinfo(int (*func_ioinfo)(const char *path, - int fd, u_int32_t *mbytesp, u_int32_t *bytesp, u_int32_t *iosizep)); -
The Berkeley DB library requires the ability to determine the size and I/O -characteristics of a file. The func_ioinfo argument must conform -to the following interface: -
-int ioinfo(const char *path, int fd, -u_int32_t *mbytesp, u_int32_t *bytesp, u_int32_t *iosizep);
The path argument is the pathname of the file to be checked, and the -fd argument is an open file descriptor on the file. -
If the mbytesp and bytesp arguments are non-NULL, the -ioinfo function must return in them the size of the file: the -number of megabytes in the file into the memory location referenced by -the mbytesp argument, and the number of bytes over and above that -number of megabytes into the memory location referenced by the -bytesp argument. -
In addition, if the iosizep argument is non-NULL, the ioinfo -function must return the optimum granularity for I/O operations to the file -in the memory location referenced by it. -
The func_ioinfo function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_ioinfo interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_ioinfo interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_ioinfo function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_malloc.html b/bdb/docs/api_c/set_func_malloc.html deleted file mode 100644 index a4be5bfb04e..00000000000 --- a/bdb/docs/api_c/set_func_malloc.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-db_env_set_func_malloc- |
-
-
- |
-#include <db.h> --int -db_env_set_func_malloc(void *(*func_malloc)(size_t size)); -
Replace Berkeley DB calls to the ANSI C X3.159-1989 (ANSI C) standard -malloc function with func_malloc, which must conform to -the standard interface. -
The db_env_set_func_malloc interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_malloc interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_malloc function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_map.html b/bdb/docs/api_c/set_func_map.html deleted file mode 100644 index e14e9c4aad7..00000000000 --- a/bdb/docs/api_c/set_func_map.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - -
-
-db_env_set_func_map- |
-
-
- |
-#include <db.h> --int -db_env_set_func_map(int (*func_map)(char *path, - size_t len, int is_region, int is_rdonly, void **addr)); -
The Berkeley DB library requires the ability to map a file into memory and to -create shared memory regions (which may or may not be backed by files). -The func_map argument must conform to the following interface: -
-int map(char *path, size_t len, -int is_region, int is_rdonly, void **addr);
The path argument is the name of a file. -
The is_region argument will be zero if the intention is to map a -file into shared memory. In this case, the map function must map -the first len bytes of the file into memory and return a pointer -to the mapped location in the memory location referenced by the argument -addr. The is_rdonly argument will be non-zero if the file -is considered read-only by the caller. -
The is_region argument will be non-zero if the memory is intended -to be used as a shared memory region for synchronization between Berkeley DB -threads/processes. In this case, the returned memory may be of any kind -(e.g., anonymous), but must be able to support semaphores. In this case, -the path argument may be ignored (although future map -calls using the same path must return the same memory), and the -is_rdonly argument will always be zero. -
The func_map function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_map interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_map interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_map function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_open.html b/bdb/docs/api_c/set_func_open.html deleted file mode 100644 index ff72d9882ed..00000000000 --- a/bdb/docs/api_c/set_func_open.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-db_env_set_func_open- |
-
-
- |
-#include <db.h> --int -db_env_set_func_open(int (*func_open)(const char *path, int flags, int mode)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) open function -with func_open, which must conform to the standard interface. -
The db_env_set_func_open interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_open interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_open function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_read.html b/bdb/docs/api_c/set_func_read.html deleted file mode 100644 index b3ee9308118..00000000000 --- a/bdb/docs/api_c/set_func_read.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-db_env_set_func_read- |
-
-
- |
-#include <db.h> --int -db_env_set_func_read(ssize_t (*func_read)(int fd, void *buf, size_t nbytes)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) read function -with func_read, which must conform to the standard interface. -
The db_env_set_func_read interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_read interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_read function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_realloc.html b/bdb/docs/api_c/set_func_realloc.html deleted file mode 100644 index 91e5835bcca..00000000000 --- a/bdb/docs/api_c/set_func_realloc.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-db_env_set_func_realloc- |
-
-
- |
-#include <db.h> --int -db_env_set_func_realloc(void *(*func_realloc)(void *ptr, size_t size)); -
Replace Berkeley DB calls to the ANSI C X3.159-1989 (ANSI C) standard -realloc function with func_realloc, which must conform to -the standard interface. -
The db_env_set_func_realloc interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_realloc interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_realloc function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_rename.html b/bdb/docs/api_c/set_func_rename.html deleted file mode 100644 index bb588672359..00000000000 --- a/bdb/docs/api_c/set_func_rename.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-db_env_set_func_rename- |
-
-
- |
-#include <db.h> --int -db_env_set_func_rename(int (*func_rename)(int fd)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) close function -with func_close, which must conform to the standard interface. -
The db_env_set_func_rename interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_rename interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_rename function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_seek.html b/bdb/docs/api_c/set_func_seek.html deleted file mode 100644 index dd27384f672..00000000000 --- a/bdb/docs/api_c/set_func_seek.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - -
-
-db_env_set_func_seek- |
-
-
- |
-#include <db.h> --int -db_env_set_func_seek(int (*func_seek)(int fd, size_t pgsize, - db_pgno_t pageno, u_int32_t relative, int rewind, int whence)); -
The Berkeley DB library requires the ability to specify that a subsequent read -from or write to a file will occur at a specific location in that file. -The func_seek argument must conform to the following interface: -
-int seek(int fd, size_t pgsize, db_pgno_t pageno, -u_int32_t relative, int rewind, int whence);
The fd argument is an open file descriptor on the file. -
The seek function must cause a subsequent read from or write to -the file to occur at a byte offset specified by the calculation: -
-(pgsize * pageno) + relative
If rewind is non-zero, the byte offset is treated as a backwards -seek, not a forwards one. -
The whence argument specifies where in the file the byte offset -is relative to, as described by the IEEE/ANSI Std 1003.1 (POSIX) lseek system -call. -
The func_seek function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_seek interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_seek interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_seek function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_sleep.html b/bdb/docs/api_c/set_func_sleep.html deleted file mode 100644 index dd454b1a725..00000000000 --- a/bdb/docs/api_c/set_func_sleep.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-db_env_set_func_sleep- |
-
-
- |
-#include <db.h> --int -db_env_set_func_sleep(int (*func_sleep)(u_long seconds, u_long microseconds)); -
The Berkeley DB library requires the ability to cause a process to suspend itself -for a period of time, relinquishing control of the processor to any other -waiting thread of control. The func_sleep argument must conform -to the following interface: -
-int sleep(u_long seconds, u_long microseconds);
The seconds and microseconds arguments specify the amount -of time to wait until the suspending thread of control should run again. -
The seconds and microseconds arguments may not be -normalized when the sleep function is called, i.e., the -microseconds argument may be greater than 1000000. -
The func_sleep function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_sleep interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_sleep interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_sleep function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_unlink.html b/bdb/docs/api_c/set_func_unlink.html deleted file mode 100644 index 1e5e8e3cba9..00000000000 --- a/bdb/docs/api_c/set_func_unlink.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-db_env_set_func_unlink- |
-
-
- |
-#include <db.h> --int -db_env_set_func_unlink(int (*func_unlink)(const char *path)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) unlink function -with func_unlink, which must conform to the standard interface. -
The db_env_set_func_unlink interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_unlink interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_unlink function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_unmap.html b/bdb/docs/api_c/set_func_unmap.html deleted file mode 100644 index 07635b48a80..00000000000 --- a/bdb/docs/api_c/set_func_unmap.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-db_env_set_func_unmap- |
-
-
- |
-#include <db.h> --int -db_env_set_func_unmap(int (*func_unmap)(void *addr, size_t len)); -
The Berkeley DB library requires the ability to unmap a file or shared memory -region from memory. The func_unmap argument must conform to the -following interface: -
-int unmap(void *addr, size_t len);
The addr argument is the argument returned by the -db_env_set_func_map function when the file or region was mapped -into memory, and the len argument is the same as the len -argument specified to the db_env_set_func_map function when the -file or region was mapped into memory. -
The func_unmap function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_unmap interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_unmap interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_unmap function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_write.html b/bdb/docs/api_c/set_func_write.html deleted file mode 100644 index 7b52b5078ba..00000000000 --- a/bdb/docs/api_c/set_func_write.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-db_env_set_func_write- |
-
-
- |
-#include <db.h> --int -db_env_set_func_write( - ssize_t (*func_write)(int fd, const void *buffer, size_t nbytes)); -
Replace Berkeley DB calls to the IEEE/ANSI Std 1003.1 (POSIX) write function -with func_write, which must conform to the standard interface. -
The db_env_set_func_write interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_write interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_write function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/set_func_yield.html b/bdb/docs/api_c/set_func_yield.html deleted file mode 100644 index 23915aea68b..00000000000 --- a/bdb/docs/api_c/set_func_yield.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-db_env_set_func_yield- |
-
-
- |
-#include <db.h> --int -db_env_set_func_yield(int (*func_yield)(void)); -
The Berkeley DB library requires the ability to yield the processor from the current -thread of control to any other waiting threads of control. -The func_yield argument must conform to the following interface: -
-int yield(void);
The func_yield function must be able to cause the rescheduling -all participants in the current Berkeley DB environment, whether threaded or -not. It may be incorrect to supply a thread yield function if -more than a single process is operating in the Berkeley DB environment. This -is because many thread-yield functions will not allow other processes to -run, and the contested lock may be held by another process, not by another -thread. -
If no func_yield function is specified, or if the yield -function returns an error, the function specified by the -db_env_set_func_sleep entry will be used instead or subsequently, -i.e., if no yield function is specified, or it is possible for -the yield function to fail, the sleep function -must cause the processor to reschedule any waiting threads of -control for execution. -
The func_yield function must return the value of errno on -failure and 0 on success. -
The db_env_set_func_yield interface affects the entire application, not a single -database or database environment. -
While the db_env_set_func_yield interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create functions. -
The db_env_set_func_yield function returns a non-zero error value on failure and 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_abort.html b/bdb/docs/api_c/txn_abort.html deleted file mode 100644 index 00056023aba..00000000000 --- a/bdb/docs/api_c/txn_abort.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-txn_abort- |
-
-
- |
-#include <db.h> --int -txn_abort(DB_TXN *tid); -
The txn_abort function causes an abnormal termination of the -transaction. The log is played backwards and any necessary recovery -operations are initiated through the recover function specified -to DBENV->open. After the log processing is completed, all locks -held by the transaction are released. As is the case for -txn_commit, applications that require strict two-phase locking -should not explicitly release any locks. -
In the case of nested transactions, aborting a parent transaction causes -all children (unresolved or not) of the parent transaction to be aborted. -
Once the txn_abort function returns, the DB_TXN handle may not -be accessed again. -
The txn_abort function returns a non-zero error value on failure and 0 on success. -
The txn_abort function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the txn_abort function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_begin.html b/bdb/docs/api_c/txn_begin.html deleted file mode 100644 index 0241d5c1fdb..00000000000 --- a/bdb/docs/api_c/txn_begin.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - -
-
-txn_begin- |
-
-
- |
-#include <db.h> --int -txn_begin(DB_ENV *env, - DB_TXN *parent, DB_TXN **tid, u_int32_t flags); -
The txn_begin method creates a new transaction in the environment -and copies a pointer to a DB_TXN that uniquely identifies it into -the memory referenced by tid. -
If the parent argument is non-NULL, the new transaction will -be a nested transaction, with the transaction indicated by -parent as its parent. Transactions may be -nested to any level. -
The flags parameter must be set to 0 or one of the following -values: -
This behavior may be set for an entire Berkeley DB environment as part of the -DBENV->set_flags interface. -
This behavior is the default for Berkeley DB environments unless the -DB_TXN_NOSYNC flag was specified to the DBENV->set_flags -interface. -
Note: An transaction may not span threads, -i.e., each transaction must begin and end in the same thread, and each -transaction may only be used by a single thread. -
Note: cursors may not span transactions, i.e., each cursor must be opened -and closed within a single transaction. -
Note: a parent transaction may not issue any Berkeley DB operations, except for -txn_begin, txn_abort and txn_commit, while it has -active child transactions (child transactions that have not yet been -committed or aborted). -
The txn_begin function returns a non-zero error value on failure and 0 on success. -
The txn_begin function may fail and return a non-zero error for the following conditions: -
The txn_begin function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the txn_begin function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_checkpoint.html b/bdb/docs/api_c/txn_checkpoint.html deleted file mode 100644 index 140edee57d7..00000000000 --- a/bdb/docs/api_c/txn_checkpoint.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-txn_checkpoint- |
-
-
- |
-#include <db.h> --int -txn_checkpoint(const DB_ENV *env, - u_int32_t kbyte, u_int32_t min, u_int32_t flags); -
The txn_checkpoint function flushes the underlying memory pool, -writes a checkpoint record to the log and then flushes the log. -
If either kbyte or min is non-zero, the checkpoint is only -done if there has been activity since the last checkpoint and either -more than min minutes have passed since the last checkpoint, -or if more than kbyte kilobytes of log data have been written since -the last checkpoint. -
The flags parameter must be set to 0 or one of the following -values: -
The txn_checkpoint function returns a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if there were pages that needed to be -written to complete the checkpoint but that memp_sync was unable -to write immediately. -
The txn_checkpoint function is the underlying function used by the db_checkpoint utility. -See the db_checkpoint utility source code for an example of using txn_checkpoint -in a IEEE/ANSI Std 1003.1 (POSIX) environment. -
The txn_checkpoint function may fail and return a non-zero error for the following conditions: -
The txn_checkpoint function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the txn_checkpoint function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_commit.html b/bdb/docs/api_c/txn_commit.html deleted file mode 100644 index 7fca3d08d7b..00000000000 --- a/bdb/docs/api_c/txn_commit.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-txn_commit- |
-
-
- |
-#include <db.h> --int -txn_commit(DB_TXN *tid, u_int32_t flags); -
The txn_commit function ends the transaction. In the case of nested -transactions, if the transaction is a parent transaction, committing -the parent transaction causes all unresolved children of the parent to -be committed. -
In the case of nested transactions, if the transaction is a child -transaction, its locks are not released, but are acquired by its parent. -While the commit of the child transaction will succeed, the actual -resolution of the child transaction is postponed until the parent -transaction is committed or aborted, i.e., if its parent transaction -commits, it will be committed, and if its parent transaction aborts, it -will be aborted. -
The flags parameter must be set to 0 or one of the following -values: -
This behavior may be set for an entire Berkeley DB environment as part of the -DBENV->set_flags interface. -
This behavior is the default for Berkeley DB environments unless the -DB_TXN_NOSYNC flag was specified to the DBENV->set_flags -or txn_begin interfaces. -
Once the txn_commit function returns, the DB_TXN handle may not -be accessed again. If txn_commit encounters an error, the -transaction and all child transactions of the transaction are aborted. -
The txn_commit function returns a non-zero error value on failure and 0 on success. -
The txn_commit function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the txn_commit function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_id.html b/bdb/docs/api_c/txn_id.html deleted file mode 100644 index bcda4bcdfff..00000000000 --- a/bdb/docs/api_c/txn_id.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - -
-
-txn_id- |
-
-
- |
-#include <db.h> --u_int32_t -txn_id(DB_TXN *tid); -
The txn_id function returns the unique transaction id associated with the -specified transaction. Locking calls made on behalf of this transaction -should use the value returned from txn_id as the locker parameter -to the lock_get or lock_vec calls. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_prepare.html b/bdb/docs/api_c/txn_prepare.html deleted file mode 100644 index 549a6f074a0..00000000000 --- a/bdb/docs/api_c/txn_prepare.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-txn_prepare- |
-
-
- |
-#include <db.h> --int -txn_prepare(DB_TXN *tid); -
The txn_prepare function initiates the beginning of a two-phase commit. -
In a distributed transaction environment, Berkeley DB can be used as a local -transaction manager. In this case, the distributed transaction manager -must send prepare messages to each local manager. The local -manager must then issue a txn_prepare and await its successful -return before responding to the distributed transaction manager. Only -after the distributed transaction manager receives successful responses -from all of its prepare messages should it issue any -commit messages. -
In the case of nested transactions, preparing a parent transaction -causes all unresolved children of the parent transaction to be prepared. -
The txn_prepare function returns a non-zero error value on failure and 0 on success. -
The txn_prepare function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the txn_prepare function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_c/txn_stat.html b/bdb/docs/api_c/txn_stat.html deleted file mode 100644 index 769283f93c2..00000000000 --- a/bdb/docs/api_c/txn_stat.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-txn_stat- |
-
-
- |
-#include <db.h> --int -txn_stat(DB_ENV *env, - DB_TXN_STAT **statp, void *(*db_malloc)(size_t)); -
The txn_stat function -creates a statistical structure and copies a pointer to it into a -user-specified memory location. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The transaction region statistics are stored in a structure of type -DB_TXN_STAT. The following DB_TXN_STAT fields will be filled in: -
The txn_stat function returns a non-zero error value on failure and 0 on success. -
The txn_stat function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. -If a catastrophic error has occurred, the txn_stat function may fail and return -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/cxx_index.html b/bdb/docs/api_cxx/cxx_index.html deleted file mode 100644 index 1ba43a0f227..00000000000 --- a/bdb/docs/api_cxx/cxx_index.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - -
-| Class | Method | Description |
|---|---|---|
| DbEnv | Berkeley DB Environment Class | |
| DbEnv::close | Close an environment | |
| DbEnv::err | Error message with error string | |
| DbEnv::errx | Error message | |
| DbEnv::open | Open an environment | |
| DbEnv::remove | Remove an environment | |
| DbEnv::set_cachesize | Set the environment cache size | |
| DbEnv::set_data_dir | Set the environment data directory | |
| DbEnv::set_errcall | Set error message callback | |
| DbEnv::set_errfile | Set error message FILE * | |
| DbEnv::set_error_stream | Set error message output stream | |
| DbEnv::set_errpfx | Set error message prefix | |
| DbEnv::set_feedback | Set feedback callback | |
| DbEnv::set_flags | Environment configuration | |
| DbEnv::set_lg_bsize | Set log buffer size | |
| DbEnv::set_lg_dir | Set the environment logging directory | |
| DbEnv::set_lg_max | Set log file size | |
| DbEnv::set_lk_conflicts | Set lock conflicts matrix | |
| DbEnv::set_lk_detect | Set automatic deadlock detection | |
| DbEnv::set_lk_max | Set maximum number of locks (Deprecated) | |
| DbEnv::set_lk_max_locks | Set maximum number of locks | |
| DbEnv::set_lk_max_lockers | Set maximum number of lockers | |
| DbEnv::set_lk_max_objects | Set maximum number of lock objects | |
| DbEnv::set_mp_mmapsize | Set maximum mapped-in database file size | |
| DbEnv::set_mutexlocks | Turn off mutual exclusion locking | |
| DbEnv::set_pageyield | Yield the processor on each page access | |
| DbEnv::set_paniccall | Set panic callback | |
| DbEnv::set_panicstate | Reset panic state | |
| DbEnv::set_recovery_init | Set recovery initialization callback | |
| DbEnv::set_region_init | Fault in shared regions on initial access | |
| DbEnv::set_server | Establish server connection | |
| DbEnv::set_shm_key | Set system memory shared segment ID | |
| DbEnv::set_tas_spins | Set the number of test-and-set spins | |
| DbEnv::set_tmp_dir | Set the environment temporary file directory | |
| DbEnv::set_tx_max | Set maximum number of transactions | |
| DbEnv::set_tx_recover | Set transaction abort recover function | |
| DbEnv::set_tx_timestamp | Set recovery timestamp | |
| DbEnv::set_verbose | Set verbose messages | |
| DbEnv::strerror | Error strings | |
| DbEnv::lock_detect | Perform deadlock detection | |
| DbEnv::lock_get | Acquire a lock | |
| DbEnv::lock_id | Acquire a locker ID | |
| DbEnv::lock_stat | Return lock subsystem statistics | |
| DbEnv::lock_vec | Acquire/release locks | |
| DbEnv::log_archive | List log and database files | |
| DbEnv::log_compare | Compare two Log Sequence Numbers | |
| DbEnv::log_file | Map Log Sequence Numbers to log files | |
| DbEnv::log_flush | Flush log records | |
| DbEnv::log_get | Get a log record | |
| DbEnv::log_put | Write a log record | |
| DbEnv::log_register | Register a file name with the log manager | |
| DbEnv::log_stat | Return log subsystem statistics | |
| DbEnv::log_unregister | Unregister a file name with the log manager | |
| DbEnv::memp_register | Register input/output functions for a file in a buffer pool. | |
| DbEnv::memp_stat | Return buffer pool statistics | |
| DbEnv::memp_sync | Flush pages from a buffer pool | |
| DbEnv::memp_trickle | Trickle flush pages from a buffer pool | |
| DbEnv::txn_begin | Begin a transaction | |
| DbEnv::txn_checkpoint | Checkpoint the transaction subsystem | |
| DbEnv::txn_stat | Return transaction subsystem statistics | |
| DbEnv::version | Return version information | |
| Db | Berkeley DB Access Method Class | |
| Db::close | Close a database | |
| Db::cursor | Open a cursor into a database | |
| Db::del | Delete items from a database | |
| Db::err | Error message with error string | |
| Db::errx | Error message | |
| Db::fd | Return a file descriptor from a database | |
| Db::get | Get items from a database | |
| Db::get_byteswapped | Return if the underlying database is in host order | |
| Db::get_type | Return the database type | |
| Db::join | Perform a database join on cursors | |
| Db::key_range | Return estimate of key location | |
| Db::open | Open a database | |
| Db::put | Store items into a database | |
| Db::remove | Remove a database | |
| Db::rename | Rename a database | |
| Db::set_append_recno | Set record append callback | |
| Db::set_bt_compare | Set a Btree comparison function | |
| Db::set_bt_minkey | Set the minimum number of keys per Btree page | |
| Db::set_bt_prefix | Set a Btree prefix comparison function | |
| Db::set_cachesize | Set the database cache size | |
| Db::set_dup_compare | Set a duplicate comparison function | |
| Db::set_errcall | Set error message callback | |
| Db::set_errfile | Set error message FILE * | |
| Db::set_errpfx | Set error message prefix | |
| Db::set_feedback | Set feedback callback | |
| Db::set_flags | General database configuration | |
| Db::set_h_ffactor | Set the Hash table density | |
| Db::set_h_hash | Set a hashing function | |
| Db::set_h_nelem | Set the Hash table size | |
| Db::set_lorder | Set the database byte order | |
| Db::set_malloc | Set a local space allocation function | |
| Db::set_pagesize | Set the underlying database page size | |
| Db::set_paniccall | Set panic callback | |
| Db::set_q_extentsize | Set Queue database extent size | |
| Db::set_re_delim | Set the variable-length record delimiter | |
| Db::set_re_len | Set the fixed-length record length | |
| Db::set_re_pad | Set the fixed-length record pad byte | |
| Db::set_re_source | Set the backing Recno text file | |
| Db::set_realloc | Set a local space allocation function | |
| Db::stat | Return database statistics | |
| Db::sync | Flush a database to stable storage | |
| Db::upgrade | Upgrade a database | |
| Db::verify | Verify/upgrade a database | |
| Dbc | Berkeley DB Cursor Class | |
| Dbc::close | Close a cursor | |
| Dbc::count | Return count of duplicates | |
| Dbc::del | Delete by cursor | |
| Dbc::dup | Duplicate a cursor | |
| Dbc::get | Retrieve by cursor | |
| Dbc::put | Store by cursor | |
| Dbt | Key/Data Encoding Class | |
| DbLock | Lock Class | |
| DbLock::put | Release a lock | |
| DbLsn | Log Sequence Number Class | |
| DbMpoolFile | Memory Pool File Class | |
| DbMpoolFile::close | Close a file in a buffer pool | |
| DbMpoolFile::get | Get page from a file in a buffer pool | |
| DbMpoolFile::open | Open a file in a buffer pool | |
| DbMpoolFile::put | Return a page to a buffer pool | |
| DbMpoolFile::set | Modify meta information for buffer pool page | |
| DbMpoolFile::sync | Flush pages from a file in a buffer pool | |
| DbTxn | Transaction Class | |
| DbTxn::abort | Abort a transaction | |
| DbTxn::commit | Commit a transaction | |
| DbTxn::id | Return a transaction ID | |
| DbTxn::prepare | Prepare a transaction for commit | |
| DbException | Exception Class for Berkeley DB Activity | |
| DbException::get_errno | Get the error value | |
| DbException::what | Get the error string |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/cxx_pindex.html b/bdb/docs/api_cxx/cxx_pindex.html deleted file mode 100644 index d460fcf65c4..00000000000 --- a/bdb/docs/api_cxx/cxx_pindex.html +++ /dev/null @@ -1,516 +0,0 @@ - -
-| configuring Berkeley DB | 1.85 API compatibility |
| building a utility to dump Berkeley DB | 1.85 databases |
| Upgrading to release | 2.0 |
| Upgrading to release | 3.0 |
| Upgrading to release | 3.1 |
| Upgrading to release | 3.2 |
| selecting an | access method |
| access methods | |
| AIX | |
| data | alignment |
| programmatic | APIs |
| utility to | archive log files |
| berkeley_db_svc | |
| building for UNIX | |
| building for UNIX FAQ | |
| building for VxWorks | |
| building for VxWorks FAQ | |
| building for Win32 | |
| building for Windows FAQ | |
| selecting a | byte order |
| byte ordering | |
| configuring the | C++ API |
| flushing the database | cache |
| selecting a | cache size |
| catastrophic recovery | |
| Patches, Updates and | Change logs |
| utility to take | checkpoints |
| DbMpoolFile::open | clear_len |
| closing a cursor | |
| closing a database | |
| specifying a Btree | comparison function |
| changing | compile or load options |
| Concurrent Data Store | |
| configuring Berkeley DB for UNIX systems | |
| recovering | corrupted databases |
| counting data items for a key | |
| closing a | cursor |
| deleting records with a | cursor |
| duplicating a | cursor |
| retrieving records with a | cursor |
| storing records with a | cursor |
| cursor stability | |
| database | cursors |
| Dbt | data |
| utility to upgrade | database files |
| utility to verify | database files |
| Db | |
| Dbc::put | DB_AFTER |
| Db::verify | DB_AGGRESSIVE |
| Db::put | DB_APPEND |
| DbEnv::log_archive | DB_ARCH_ABS |
| DbEnv::log_archive | DB_ARCH_DATA |
| db_archive | |
| DbEnv::log_archive | DB_ARCH_LOG |
| Dbc::put | DB_BEFORE |
| Dbc | |
| Db::stat | DB_CACHED_COUNTS |
| Dbc::close | |
| Dbc::count | |
| DbEnv::set_flags | DB_CDB_ALLDB |
| Dbc::del | |
| Dbc::dup | |
| Dbc::get | |
| DbEnv::log_get | DB_CHECKPOINT |
| DbEnv::log_put | DB_CHECKPOINT |
| db_checkpoint | |
| DbEnv | DB_CLIENT |
| Db::close | |
| File naming | DB_CONFIG |
| Db::get | DB_CONSUME |
| Db::get | DB_CONSUME_WAIT |
| Dbc::put | |
| Db::open | DB_CREATE |
| DbEnv::open | DB_CREATE |
| DbMpoolFile::open | DB_CREATE |
| DbEnv::log_put | DB_CURLSN |
| Dbc::get | DB_CURRENT |
| Dbc::put | DB_CURRENT |
| DbEnv::log_get | DB_CURRENT |
| Db::cursor | |
| Db | DB_CXX_NO_EXCEPTIONS |
| DbEnv | DB_CXX_NO_EXCEPTIONS |
| Dbt | DB_DBT_MALLOC |
| Dbt | DB_DBT_PARTIAL |
| Dbt | DB_DBT_REALLOC |
| Dbt | DB_DBT_USERMEM |
| db_deadlock | |
| Db::del | |
| db_dump | |
| Db::set_flags | DB_DUP |
| Db::set_flags | DB_DUPSORT |
| Db::upgrade | DB_DUPSORT |
| DbEnv | |
| DbEnv::close | |
| DbEnv::err | |
| DbEnv::lock_detect | |
| DbEnv::lock_get | |
| DbEnv::lock_id | |
| DbEnv::lock_stat | |
| DbEnv::lock_vec | |
| DbEnv::log_archive | |
| DbEnv::log_compare | |
| DbEnv::log_file | |
| DbEnv::log_flush | |
| DbEnv::log_get | |
| DbEnv::log_put | |
| DbEnv::log_register | |
| DbEnv::log_stat | |
| DbEnv::log_unregister | |
| DbEnv::memp_register | |
| DbEnv::memp_stat | |
| DbEnv::memp_sync | |
| DbEnv::memp_trickle | |
| DbEnv::open | |
| DbEnv::remove | |
| DbEnv::set_cachesize | |
| DbEnv::set_data_dir | |
| DbEnv::set_errcall | |
| DbEnv::set_errfile | |
| DbEnv::set_error_stream | |
| DbEnv::set_errpfx | |
| DbEnv::set_feedback | |
| DbEnv::set_flags | |
| DbEnv::set_lg_bsize | |
| DbEnv::set_lg_dir | |
| DbEnv::set_lg_max | |
| DbEnv::set_lk_conflicts | |
| DbEnv::set_lk_detect | |
| DbEnv::set_lk_max | |
| DbEnv::set_lk_max_lockers | |
| DbEnv::set_lk_max_locks | |
| DbEnv::set_lk_max_objects | |
| DbEnv::set_mp_mmapsize | |
| DbEnv::set_mutexlocks | |
| DbEnv::set_pageyield | |
| DbEnv::set_paniccall | |
| DbEnv::set_panicstate | |
| DbEnv::set_recovery_init | |
| DbEnv::set_region_init | |
| DbEnv::set_server | |
| DbEnv::set_shm_key | |
| DbEnv::set_tas_spins | |
| DbEnv::set_tmp_dir | |
| DbEnv::set_tx_max | |
| DbEnv::set_tx_recover | |
| DbEnv::set_tx_timestamp | |
| DbEnv::set_verbose | |
| DbEnv::strerror | |
| DbEnv::txn_begin | |
| DbEnv::txn_checkpoint | |
| DbEnv::txn_stat | |
| DbEnv::version | |
| DbException | |
| DbException::get_errno | |
| DbException::what | |
| Db::open | DB_EXCL |
| Db::fd | |
| Dbc::get | DB_FIRST |
| DbEnv::log_get | DB_FIRST |
| DbEnv::log_put | DB_FLUSH |
| DbEnv::remove | DB_FORCE |
| DbEnv::txn_checkpoint | DB_FORCE |
| Db::get | |
| Db::get | DB_GET_BOTH |
| Dbc::get | DB_GET_BOTH |
| Db::get_byteswapped | |
| Dbc::get | DB_GET_RECNO |
| Db::get_type | |
| File naming | DB_HOME |
| File naming | db_home |
| Db::close | DB_INCOMPLETE |
| DbEnv::open | DB_INIT_CDB |
| DbEnv::open | DB_INIT_LOCK |
| DbEnv::open | DB_INIT_LOG |
| DbEnv::open | DB_INIT_MPOOL |
| DbEnv::open | DB_INIT_TXN |
| Db::join | |
| DbEnv::open | DB_JOINENV |
| Db::join | DB_JOIN_ITEM |
| Dbc::get | DB_JOIN_ITEM |
| Db::join | DB_JOIN_NOSORT |
| Error returns to applications | DB_KEYEMPTY |
| Dbc::put | DB_KEYFIRST |
| Dbc::put | DB_KEYLAST |
| Db::key_range | |
| Dbc::get | DB_LAST |
| DbEnv::log_get | DB_LAST |
| db_load | |
| DbLock | |
| DbEnv::lock_detect | DB_LOCK_CONFLICT |
| Error returns to applications | DB_LOCK_DEADLOCK |
| DbEnv::set_lk_detect | DB_LOCK_DEFAULT |
| DbEnv::open | DB_LOCKDOWN |
| DbEnv::lock_vec | DB_LOCK_GET |
| DbEnv::lock_get | DB_LOCK_NOTGRANTED |
| DbEnv::lock_vec | DB_LOCK_NOTGRANTED |
| Error returns to applications | DB_LOCK_NOTGRANTED |
| DbEnv::lock_get | DB_LOCK_NOWAIT |
| DbEnv::lock_vec | DB_LOCK_NOWAIT |
| DbEnv::set_lk_detect | DB_LOCK_OLDEST |
| DbLock::put | |
| DbEnv::lock_vec | DB_LOCK_PUT |
| DbEnv::lock_vec | DB_LOCK_PUT_ALL |
| DbEnv::lock_vec | DB_LOCK_PUT_OBJ |
| DbEnv::set_lk_detect | DB_LOCK_RANDOM |
| DbEnv::set_lk_detect | DB_LOCK_YOUNGEST |
| DbLsn | |
| DbMpoolFile::put | DB_MPOOL_CLEAN |
| DbMpoolFile::set | DB_MPOOL_CLEAN |
| DbMpoolFile::get | DB_MPOOL_CREATE |
| DbMpoolFile::put | DB_MPOOL_DIRTY |
| DbMpoolFile::set | DB_MPOOL_DIRTY |
| DbMpoolFile::put | DB_MPOOL_DISCARD |
| DbMpoolFile::set | DB_MPOOL_DISCARD |
| DbMpoolFile | |
| DbMpoolFile::close | |
| DbMpoolFile::get | |
| DbMpoolFile::open | |
| DbMpoolFile::put | |
| DbMpoolFile::set | |
| DbMpoolFile::sync | |
| DbMpoolFile::get | DB_MPOOL_LAST |
| DbMpoolFile::get | DB_MPOOL_NEW |
| Dbc::get | DB_NEXT |
| DbEnv::log_get | DB_NEXT |
| Dbc::get | DB_NEXT_DUP |
| Dbc::get | DB_NEXT_NODUP |
| Db::put | DB_NODUPDATA |
| Dbc::put | DB_NODUPDATA |
| Db::open | DB_NOMMAP |
| DbEnv::set_flags | DB_NOMMAP |
| DbMpoolFile::open | DB_NOMMAP |
| Db::verify | DB_NOORDERCHK |
| Db::put | DB_NOOVERWRITE |
| DbEnv::set_server | DB_NOSERVER |
| DbEnv::set_server | DB_NOSERVER_ID |
| Db::close | DB_NOSYNC |
| Error returns to applications | DB_NOTFOUND |
| Db::open | DB_OLD_VERSION |
| Db::upgrade | DB_OLD_VERSION |
| Db::open | |
| Db::verify | DB_ORDERCHKONLY |
| Dbc::dup | DB_POSITION |
| Dbc::get | DB_PREV |
| DbEnv::log_get | DB_PREV |
| Dbc::get | DB_PREV_NODUP |
| db_printlog | |
| DbEnv::open | DB_PRIVATE |
| Db::put | |
| Db::open | DB_RDONLY |
| DbMpoolFile::open | DB_RDONLY |
| Db::set_flags | DB_RECNUM |
| Db::stat | DB_RECORDCOUNT |
| DbEnv::open | DB_RECOVER |
| DbEnv::set_feedback | DB_RECOVER |
| db_recover | |
| DbEnv::open | DB_RECOVER_FATAL |
| Db::remove | |
| Db::rename | |
| Db::set_flags | DB_RENUMBER |
| Db::set_flags | DB_REVSPLITOFF |
| Db::get | DB_RMW |
| Db::join | DB_RMW |
| Dbc::get | DB_RMW |
| Error returns to applications | DB_RUNRECOVERY |
| Db::verify | DB_SALVAGE |
| Dbc::get | DB_SET |
| DbEnv::log_get | DB_SET |
| Db::set_append_recno | |
| Db::set_bt_compare | |
| Db::set_bt_minkey | |
| Db::set_bt_prefix | |
| Db::set_cachesize | |
| Db::set_dup_compare | |
| Db::set_errcall | |
| Db::set_errfile | |
| Db::set_errpfx | |
| Db::set_feedback | |
| Db::set_flags | |
| Db::set_h_ffactor | |
| Db::set_h_hash | |
| Db::set_h_nelem | |
| Db::set_lorder | |
| Db::set_malloc | |
| Db::set_pagesize | |
| Db::set_paniccall | |
| Db::set_q_extentsize | |
| Dbc::get | DB_SET_RANGE |
| Db::set_realloc | |
| Db::get | DB_SET_RECNO |
| Dbc::get | DB_SET_RECNO |
| Db::set_re_delim | |
| Db::set_re_len | |
| Db::set_re_pad | |
| Db::set_re_source | |
| Db::set_flags | DB_SNAPSHOT |
| Db::stat | |
| db_stat | |
| Db::sync | |
| DbEnv::open | DB_SYSTEM_MEM |
| Dbt | |
| Db::open | DB_THREAD |
| DbEnv::open | DB_THREAD |
| Db::open | DB_TRUNCATE |
| DbTxn | |
| DbEnv::set_tx_recover | DB_TXN_ABORT |
| DbTxn::abort | |
| DbEnv::set_tx_recover | DB_TXN_BACKWARD_ROLL |
| DbTxn::commit | |
| DbEnv::set_tx_recover | DB_TXN_FORWARD_ROLL |
| DbTxn::id | |
| DbEnv::set_flags | DB_TXN_NOSYNC |
| DbEnv::txn_begin | DB_TXN_NOSYNC |
| DbTxn::commit | DB_TXN_NOSYNC |
| DbEnv::txn_begin | DB_TXN_NOWAIT |
| DbTxn::prepare | |
| DbEnv::txn_begin | DB_TXN_SYNC |
| DbTxn::commit | DB_TXN_SYNC |
| Db::set_feedback | DB_UPGRADE |
| Db::upgrade | |
| db_upgrade | |
| DbEnv::open | DB_USE_ENVIRON |
| DbEnv::remove | DB_USE_ENVIRON |
| DbEnv::open | DB_USE_ENVIRON_ROOT |
| DbEnv::remove | DB_USE_ENVIRON_ROOT |
| DbEnv::set_verbose | DB_VERB_CHKPOINT |
| DbEnv::set_verbose | DB_VERB_DEADLOCK |
| DbEnv::set_verbose | DB_VERB_RECOVERY |
| DbEnv::set_verbose | DB_VERB_WAITSFOR |
| Db::set_feedback | DB_VERIFY |
| Db::verify | |
| db_verify | |
| Db::cursor | DB_WRITECURSOR |
| Db | DB_XA_CREATE |
| deadlocks | |
| utility to detect | deadlocks |
| debugging applications | |
| deleting records | |
| deleting records with a cursor | |
| Configuring Berkeley DB | --disable-bigfile |
| disk space requirements | |
| utility to | dump databases as text files |
| duplicate data items | |
| duplicating a cursor | |
| configuring | dynamic shared libraries |
| Configuring Berkeley DB | --enable-compat185 |
| Configuring Berkeley DB | --enable-cxx |
| Configuring Berkeley DB | --enable-debug |
| Configuring Berkeley DB | --enable-debug_rop |
| Configuring Berkeley DB | --enable-debug_wop |
| Configuring Berkeley DB | --enable-diagnostic |
| Configuring Berkeley DB | --enable-dump185 |
| Configuring Berkeley DB | --enable-dynamic |
| Configuring Berkeley DB | --enable-java |
| Configuring Berkeley DB | --enable-posixmutexes |
| Configuring Berkeley DB | --enable-rpc |
| Configuring Berkeley DB | --enable-shared |
| Configuring Berkeley DB | --enable-tcl |
| Configuring Berkeley DB | --enable-test |
| Configuring Berkeley DB | --enable-uimutexes |
| Configuring Berkeley DB | --enable-umrw |
| byte | endian |
| database | environment |
| environment variables | |
| error handling | |
| error name space | |
| error returns | |
| /etc/magic | |
| selecting a Queue | extent size |
| Java | FAQ |
| Tcl | FAQ |
| configuring without large | file support |
| file utility | |
| DbMpoolFile::open | fileid |
| recovery and | filesystem operations |
| remote | filesystems |
| page | fill factor |
| FreeBSD | |
| Berkeley DB | free-threaded handles |
| DbMpoolFile::open | ftype |
| specifying a database | hash |
| hash table size | |
| HP-UX | |
| installing Berkeley DB for UNIX systems | |
| interface compatibility | |
| IRIX | |
| configuring the | Java API |
| Java compatibility | |
| Java configuration | |
| Java FAQ | |
| logical | join |
| key/data pairs | |
| retrieved | key/data permanence |
| database | limits |
| Linux | |
| changing compile or | load options |
| utility to | load text files into databases |
| DbEnv::lock_vec | lock |
| standard | lock modes |
| page-level | locking |
| two-phase | locking |
| locking and non-Berkeley DB applications | |
| locking configuration | |
| locking conventions | |
| Berkeley DB Concurrent Data Store | locking conventions |
| locking introduction | |
| sizing the | locking subsystem |
| locking without transactions | |
| log file limits | |
| log file removal | |
| utility to display | log files as text |
| logging configuration | |
| logging introduction | |
| DbMpoolFile::open | lsn_offset |
| memory pool configuration | |
| DbEnv::lock_vec | mode |
| Berkeley DB library | name spaces |
| file | naming |
| retrieving Btree records by | number |
| DbEnv::lock_vec | obj |
| DbEnv::lock_vec | op |
| opening a database | |
| OSF/1 | |
| selecting a | page size |
| partial record storage and retrieval | |
| Patches, Updates and Change logs | |
| Perl | |
| retrieved key/data | permanence |
| DbMpoolFile::open | pgcookie |
| Sleepycat Software's Berkeley DB | products |
| QNX | |
| logical | record number format |
| logical | record numbers |
| managing | record-based databases |
| logically renumbering | records |
| utility to | recover database environments |
| Berkeley DB | recoverability |
| retrieving records | |
| retrieving records with a cursor | |
| RPC client | |
| configuring a | RPC client/server |
| utility to support | RPC client/server |
| RPC server | |
| database | salvage |
| SCO | |
| Berkeley DB handle | scope |
| security | |
| Sendmail | |
| configuring | shared libraries |
| shared libraries | |
| application | signal handling |
| Sleepycat Software | |
| Solaris | |
| source code layout | |
| cursor | stability |
| database | statistics |
| utility to display database and environment | statistics |
| storing records | |
| storing records with a cursor | |
| SunOS | |
| loading Berkeley DB with | Tcl |
| using Berkeley DB with | Tcl |
| configuring the | Tcl API |
| Tcl API programming notes | |
| Tcl FAQ | |
| configuring the | test suite |
| running the | test suite |
| running the | test suite under UNIX |
| running the | test suite under Windows |
| text backing files | |
| loading | text into databases |
| dumping/loading | text to/from databases |
| building | threaded applications |
| transaction configuration | |
| transaction limits | |
| administering | transaction protected applications |
| archival in | transaction protected applications |
| checkpoints in | transaction protected applications |
| deadlock detection in | transaction protected applications |
| recovery in | transaction protected applications |
| transaction throughput | |
| Transactional Data Store | |
| Berkeley DB and | transactions |
| nested | transactions |
| configuring Berkeley DB with the | Tuxedo System |
| Ultrix | |
| building for | UNIX FAQ |
| configuring Berkeley DB for | UNIX systems |
| Patches, | Updates and Change logs |
| utility to | upgrade database files |
| upgrading databases | |
| utilities | |
| database | verification |
| utility to | verify database files |
| building for | VxWorks FAQ |
| VxWorks notes | |
| running the test suite under | Windows |
| building for | Windows FAQ |
| Windows notes | |
| Configuring Berkeley DB | --with-tcl=DIR |
| XA Resource Manager |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_class.html b/bdb/docs/api_cxx/db_class.html deleted file mode 100644 index 75296aeee61..00000000000 --- a/bdb/docs/api_cxx/db_class.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - -
-
-Db- |
-
-
- |
-#include <db_cxx.h> --class Db { -public: - Db(DbEnv *dbenv, u_int32_t flags); - ~Db(); - ... -}; -
This manual page describes the specific details of the Db class, -which is the center of access method activity. -
If no dbenv value is specified, the database is standalone, i.e., -it is not part of any Berkeley DB environment. -
If a dbenv value is specified, the database is created within the -specified Berkeley DB environment. The database access methods automatically -make calls to the other subsystems in Berkeley DB based on the enclosing -environment. For example, if the environment has been configured to use -locking, then the access methods will automatically acquire the correct -locks when reading and writing pages of the database. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
If dbenv is not null, this flag is ignored and the error behavior -of the specified environment is used instead. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_close.html b/bdb/docs/api_cxx/db_close.html deleted file mode 100644 index fdde15bdb67..00000000000 --- a/bdb/docs/api_cxx/db_close.html +++ /dev/null @@ -1,123 +0,0 @@ - - - - -
-
-Db::close- |
-
-
- |
-#include <db_cxx.h> --int -Db::close(u_int32_t flags); -
The Db::close method flushes any cached database information to disk, -closes any open cursors, frees any allocated resources, and closes any -underlying files. Since key/data pairs are cached in memory, failing to -sync the file with the Db::close or Db::sync method may result -in inconsistent or lost information. -
The flags parameter must be set to 0 or the following value: -
The DB_NOSYNC flag is a dangerous option. It should only be set -if the application is doing logging (with transactions) so that the -database is recoverable after a system or application crash, or if the -database is always generated from scratch after any system or application -crash. -
It is important to understand that flushing cached information to disk -only minimizes the window of opportunity for corrupted data. -While unlikely, it is possible for database corruption to happen if a -system or application crash occurs while writing data to the database. -To ensure that database corruption never occurs, applications must either: -use transactions and logging with automatic recovery, use logging and -application-specific recovery, or edit a copy of the database, -and, once all applications using the database have successfully called -Db::close, atomically replace the original database with the -updated copy. -
When multiple threads are using the Berkeley DB handle concurrently, only a single -thread may call the Db::close method. -
Once Db::close has been called, regardless of its return, the -Db handle may not be accessed again. - -
The Db::close method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if the underlying database still has -dirty pages in the cache. (The only reason to return -DB_INCOMPLETE is if another thread of control was writing pages -in the underlying database file at the same time as the -Db::close method was called. For this reason, a return of -DB_INCOMPLETE can normally be ignored, or, in cases where it is -a possible return value, the DB_NOSYNC option should probably -have been specified.) -
The Db::close method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::close method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::close method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_cursor.html b/bdb/docs/api_cxx/db_cursor.html deleted file mode 100644 index b6954b9f329..00000000000 --- a/bdb/docs/api_cxx/db_cursor.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - -
-
-Db::cursor- |
-
-
- |
-#include <db_cxx.h> --int -Db::cursor(DbTxn *txnid, Dbc **cursorp, u_int32_t flags); -
The Db::cursor method -creates a cursor and copies a pointer to it into the memory referenced -by cursorp. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv::txn_begin, otherwise, NULL. -
If transaction protection is enabled, cursors must be opened and closed -within the context of a transaction, and the txnid parameter -specifies the transaction context in which the cursor may be used. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The Db::cursor method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::cursor method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::cursor method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::cursor method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_del.html b/bdb/docs/api_cxx/db_del.html deleted file mode 100644 index ec30c6ad01c..00000000000 --- a/bdb/docs/api_cxx/db_del.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - -
-
-Db::del- |
-
-
- |
-#include <db_cxx.h> --int -Db::del(DbTxn *txnid, Dbt *key, u_int32_t flags); -
The Db::del method removes key/data pairs from the database. The -key/data pair associated with the specified key is discarded from -the database. In the presence of duplicate key values, all records -associated with the designated key will be discarded. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv::txn_begin, otherwise, NULL. -
The flags parameter is currently unused, and must be set to 0. -
The Db::del method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and DB_NOTFOUND if the specified key did not exist in -the file. -
The Db::del method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::del method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::del method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_err.html b/bdb/docs/api_cxx/db_err.html deleted file mode 100644 index fa0bccc3926..00000000000 --- a/bdb/docs/api_cxx/db_err.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-DbEnv::err- |
-
-
- |
-#include <db_cxx.h> --DbEnv::err(int error, const char *fmt, ...); -
-DbEnv::errx(const char *fmt, ...); -
-Db::err(int error, const char *fmt, ...); -
-Db::errx(const char *fmt, ...); -
The DbEnv::err, DbEnv::errx, Db::err and -Db::errx methods provide error messaging functionality for -applications written using the Berkeley DB library. -
The DbEnv::err method constructs an error message consisting of the -following elements: -
--
-- An optional prefix string
- If no error callback method has been set using the -DbEnv::set_errcall method, any prefix string specified using the -DbEnv::set_errpfx method, followed by two separating characters: a colon -and a <space> character. -
- An optional printf-style message
- The supplied message fmt, if non-NULL, where the ANSI C X3.159-1989 (ANSI C) -printf function specifies how subsequent arguments are converted for -output. -
- A separator
- Two separating characters: a colon and a <space> character. -
- A standard error string
- The standard system or Berkeley DB library error string associated with the -error value, as returned by the DbEnv::strerror method. -
This constructed error message is then handled as follows: -
--If an error callback method has been set (see Db::set_errcall -and DbEnv::set_errcall), that method is called with two -arguments: any prefix string specified (see Db::set_errpfx and -DbEnv::set_errpfx), and the error message. -
If a C library FILE * has been set (see Db::set_errfile and -DbEnv::set_errfile), the error message is written to that output -stream. -
If a C++ ostream has been set -(see DbEnv::set_error_stream), the error message is written to that -stream. -
If none of these output options has been configured, the error message -is written to stderr, the standard error output stream.
The DbEnv::errx and Db::errx methods perform identically to the -DbEnv::err and Db::err methods except that they do not append -the final separator characters and standard error string to the error -message. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_fd.html b/bdb/docs/api_cxx/db_fd.html deleted file mode 100644 index 1cb98fb6bc7..00000000000 --- a/bdb/docs/api_cxx/db_fd.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - -
-
-Db::fd- |
-
-
- |
-#include <db_cxx.h> --int -Db::fd(int *fdp); -
The Db::fd method -copies a file descriptor representative of the underlying database into -the memory referenced by fdp. A file descriptor referencing the -same file will be returned to all processes that call Db::open with -the same file argument. This file descriptor may be safely used -as an argument to the fcntl(2) and flock(2) locking -functions. The file descriptor is not necessarily associated with any of -the underlying files actually used by the access method. -
The Db::fd method only supports a coarse-grained form of locking. -Applications should use the lock manager where possible. -
The Db::fd method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::fd method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::fd method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_get.html b/bdb/docs/api_cxx/db_get.html deleted file mode 100644 index 0cee5526b50..00000000000 --- a/bdb/docs/api_cxx/db_get.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - -
-
-Db::get- |
-
-
- |
-#include <db_cxx.h> --int -Db::get(DbTxn *txnid, Dbt *key, Dbt *data, u_int32_t flags); -
The Db::get method retrieves key/data pairs from the database. The -address -and length of the data associated with the specified key are -returned in the structure referenced by data. -
In the presence of duplicate key values, Db::get will return the -first data item for the designated key. Duplicates are sorted by insert -order except where this order has been overridden by cursor operations. -Retrieval of duplicates requires the use of cursor operations. -See Dbc::get for details. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv::txn_begin, otherwise, NULL. -
The flags parameter must be set to 0 or one of the following -values: -
The data field of the specified key -must be a pointer to a logical record number (i.e., a db_recno_t). -This record number determines the record to be retrieved. -
For DB_SET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM flag. -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
As the Db::get interface will not hold locks across -Berkeley DB interface calls in non-transactional environments, the -DB_RMW flag to the Db::get call is only meaningful in -the presence of transactions. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -the Db::get method returns DB_KEYEMPTY. -
Otherwise, if the requested key is not in the database, the -Db::get function returns DB_NOTFOUND. -
Otherwise, the Db::get method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::get method may fail and throw an exception or return a non-zero error for the following conditions: -
A record number of 0 was specified. -
The DB_THREAD flag was specified to the -Db::open method and none of the DB_DBT_MALLOC, -DB_DBT_REALLOC or DB_DBT_USERMEM flags were set in the -Dbt. -
The Db::get method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::get method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_get_byteswapped.html b/bdb/docs/api_cxx/db_get_byteswapped.html deleted file mode 100644 index 5c661fa5776..00000000000 --- a/bdb/docs/api_cxx/db_get_byteswapped.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - -
-
-Db::get_byteswapped- |
-
-
- |
-#include <db_cxx.h> --int -Db::get_byteswapped(void) const; -
The Db::get_byteswapped method returns -0 -if the underlying database files were created on an architecture -of the same byte order as the current one, and -1 -if they were not (i.e., big-endian on a little-endian machine or -vice-versa). This field may be used to determine if application -data needs to be adjusted for this architecture or not. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_get_type.html b/bdb/docs/api_cxx/db_get_type.html deleted file mode 100644 index 755032390fc..00000000000 --- a/bdb/docs/api_cxx/db_get_type.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - -
-
-Db::get_type- |
-
-
- |
-#include <db_cxx.h> --DBTYPE -Db::get_type(void) const; -
The Db::get_type method returns the type of the underlying access method -(and file format). It returns one of DB_BTREE, -DB_HASH or DB_RECNO. This value may be used to -determine the type of the database after a return from Db::open -with the type argument set to DB_UNKNOWN. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_join.html b/bdb/docs/api_cxx/db_join.html deleted file mode 100644 index 6767aaf769e..00000000000 --- a/bdb/docs/api_cxx/db_join.html +++ /dev/null @@ -1,153 +0,0 @@ - - - - -
-
-Db::join- |
-
-
- |
-#include <db_cxx.h> --int -Db::join(Dbc **curslist, Dbc **dbcp, u_int32_t flags); -
The Db::join method creates a specialized cursor for use in performing -joins on secondary indexes. For information on how to organize your data -to use this functionality, see Logical -join. -
The primary argument contains the Db handle of the primary -database, which is keyed by the data values found in entries in the -curslist. -
The curslist argument contains a NULL terminated array of cursors. -Each cursor must have been initialized to reference the key on which the -underlying database should be joined. Typically, this initialization is done -by a Dbc::get call with the DB_SET flag specified. Once the -cursors have been passed as part of a curslist, they should not -be accessed or modified until the newly created join cursor has been closed, -or else inconsistent results may be returned. -
Joined values are retrieved by doing a sequential iteration over the first -cursor in the curslist argument, and a nested iteration over each -secondary cursor in the order they are specified in the curslist -argument. This requires database traversals to search for the current -datum in all the cursors after the first. For this reason, the best join -performance normally results from sorting the cursors from the one that -references the least number of data items to the one that references the -most. By default, Db::join does this sort on behalf of its caller. -
The flags parameter must be set to 0 or the following value: -
A newly created cursor is returned in the memory location referenced by -dbcp and has the standard cursor functions: -
The flags parameter must be set to 0 or the following value: -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
For the returned join cursor to be used in a transaction protected manner, -the cursors listed in curslist must have been created within the -context of the same transaction. -
The Db::join method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::join method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::join method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::join method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_key_range.html b/bdb/docs/api_cxx/db_key_range.html deleted file mode 100644 index 980dc119ae6..00000000000 --- a/bdb/docs/api_cxx/db_key_range.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - -
-
-Db::key_range- |
-
-
- |
-#include <db_cxx.h> --int -Db::key_range(DbTxn *txnid - Dbt *key, DB_KEY_RANGE *key_range, u_int32_t flags); -
The Db::key_range method returns an estimate of the proportion of keys -that are less than, equal to and greater than the specified key. The -underlying database must be of type Btree. -
The information is returned in the key_range argument, which -contains three elements of type double, less, equal and -greater. Values are in the range of 0 to 1, e.g., if the field -less is 0.05, that indicates that 5% of the keys in the database -are less than the key argument. The value for equal will be zero -if there is no matching key and non-zero otherwise. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv::txn_begin, otherwise, NULL. -The Db::key_range method does not retain the locks it acquires for the -life of the transaction, so estimates may not be repeatable. -
The flags parameter is currently unused, and must be set to 0. -
The Db::key_range method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::key_range method may fail and throw an exception or return a non-zero error for the following conditions: -
The underlying database was not of type Btree. -
The Db::key_range method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::key_range method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_open.html b/bdb/docs/api_cxx/db_open.html deleted file mode 100644 index 4c8cb75f452..00000000000 --- a/bdb/docs/api_cxx/db_open.html +++ /dev/null @@ -1,185 +0,0 @@ - - - - -
-
-Db::open- |
-
-
- |
-#include <db_cxx.h> --int -Db::open(const char *file, - const char *database, DBTYPE type, u_int32_t flags, int mode); -
The currently supported Berkeley DB file formats (or access methods) -are Btree, Hash, Queue and Recno. The Btree format is a representation -of a sorted, balanced tree structure. The Hash format is an extensible, -dynamic hashing scheme. The Queue format supports fast access to -fixed-length records accessed by sequentially or logical record number. -The Recno format supports fixed- or variable-length records, accessed -sequentially or by logical record number, and optionally retrieved from -a flat text file. -
Storage and retrieval for the Berkeley DB access methods are based on key/data -pairs, see Dbt for more information. -
The Db::open interface opens the database represented by the -file and database arguments for both reading and writing. -The file argument is used as the name of a physical file on disk -that will be used to back the database. The database argument is -optional and allows applications to have multiple logical databases in a -single physical file. While no database argument needs to be -specified, it is an error to attempt to open a second database in a -file that was not initially created using a database name. -In-memory databases never intended to be preserved on disk may -be created by setting both the file and database arguments -to NULL. Note that in-memory databases can only ever be shared by -sharing the single database handle that created them, in circumstances -where doing so is safe. -
The type argument is of type DBTYPE -and must be set to one of DB_BTREE, DB_HASH, -DB_QUEUE, DB_RECNO or DB_UNKNOWN, except -that databases of type DB_QUEUE are restricted to one per -file. If type is DB_UNKNOWN, the database must -already exist and Db::open will automatically determine its type. -The Db::get_type method may be used to determine the underlying type of -databases opened using DB_UNKNOWN. -
The flags and mode arguments specify how files will be opened -and/or created if they do not already exist. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_EXCL flag is only meaningful when specified with the -DB_CREATE flag. -
The DB_TRUNCATE flag cannot be transaction protected, and it is -an error to specify it in a transaction protected environment. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by the access methods -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
Calling Db::open is a reasonably expensive operation, and -maintaining a set of open databases will normally be preferable to -repeatedly open and closing the database for each new query. -
The Db::open method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::open method may fail and throw an exception or return a non-zero error for the following conditions: -
-The DB_THREAD flag was specified and spinlocks are not -implemented for this architecture. -
The DB_THREAD flag was specified to Db::open, but was not -specified to the DbEnv::open call for the environment in which the -Db handle was created. -
A re_source file was specified with either the DB_THREAD -flag or the provided database environment supports transaction -processing. -
The Db::open method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::open method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_put.html b/bdb/docs/api_cxx/db_put.html deleted file mode 100644 index 5e2d1b8c4c9..00000000000 --- a/bdb/docs/api_cxx/db_put.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - -
-
-Db::put- |
-
-
- |
-#include <db_cxx.h> --int -Db::put(DbTxn *txnid, Dbt *key, Dbt *data, u_int32_t flags); -
The Db::put method stores key/data pairs in the database. The default -behavior of the Db::put function is to enter the new key/data -pair, replacing any previously existing key if duplicates are disallowed, -or adding a duplicate data item if duplicates are allowed. If the database -supports duplicates, the Db::put method adds the new data value at the -end of the duplicate set. If the database supports sorted duplicates, -the new data value is inserted at the correct sorted location. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv::txn_begin, otherwise, NULL. -
The flags parameter must be set to 0 or one of the following -values: -
There is a minor behavioral difference between the Recno and Queue access -methods for the DB_APPEND flag. If a transaction enclosing a -Db::put operation with the DB_APPEND flag aborts, the -record number may be decremented (and later re-allocated by a subsequent -DB_APPEND operation) by the Recno access method, but will not be -decremented or re-allocated by the Queue access method. -
The DB_NODUPDATA flag may not be specified to the Queue or Recno -access methods. -
Otherwise, the Db::put method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::put method may fail and throw an exception or return a non-zero error for the following conditions: -
A record number of 0 was specified. -
An attempt was made to add a record to a fixed-length database that was too -large to fit. -
An attempt was made to do a partial put. -
The Db::put method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::put method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_remove.html b/bdb/docs/api_cxx/db_remove.html deleted file mode 100644 index 56cc5a23439..00000000000 --- a/bdb/docs/api_cxx/db_remove.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - -
-
-Db::remove- |
-
-
- |
-#include <db_cxx.h> --int -Db::remove(const char *file, const char *database, u_int32_t flags); -
The Db::remove interface removes the database specified by the -file and database arguments. If no database is -specified, the physical file represented by file is removed, -incidentally removing all databases that it contained. -
If a physical file is being removed and logging is currently enabled in -the database environment, no database in the file may be open when the -Db::remove method is called. Otherwise, no reference count of database -use is maintained by Berkeley DB. Applications should not remove databases that -are currently in use. In particular, some architectures do not permit -the removal of files with open handles. On these architectures, attempts -to remove databases that are currently in use will fail. -
The flags parameter is currently unused, and must be set to 0. -
Once Db::remove has been called, regardless of its return, the -Db handle may not be accessed again. -
The Db::remove method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::remove method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::remove method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::remove method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_rename.html b/bdb/docs/api_cxx/db_rename.html deleted file mode 100644 index 03f2063d41a..00000000000 --- a/bdb/docs/api_cxx/db_rename.html +++ /dev/null @@ -1,112 +0,0 @@ - - - - -
-
-Db::rename- |
-
-
- |
-#include <db_cxx.h> --int -Db::rename(const char *file, - const char *database, const char *newname, u_int32_t flags); -
The Db::rename interface renames the database specified by the -file and database arguments to newname. If no -database is specified, the physical file represented by -file is renamed, incidentally renaming all databases that it -contained. -
If a physical file is being renamed and logging is currently enabled in -the database environment, no database in the file may be open when the -Db::rename method is called. Otherwise, no reference count of database -use is maintained by Berkeley DB. Applications should not rename databases that -are currently in use. In particular, some architectures do not permit -renaming files with open handles. On these architectures, attempts to -rename databases that are currently in use will fail. -
The flags parameter is currently unused, and must be set to 0. -
Once Db::rename has been called, regardless of its return, the -Db handle may not be accessed again. -
The Db::rename method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::rename method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::rename method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::rename method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_append_recno.html b/bdb/docs/api_cxx/db_set_append_recno.html deleted file mode 100644 index 296b4748407..00000000000 --- a/bdb/docs/api_cxx/db_set_append_recno.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-Db::set_append_recno- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_append_recno( - int (*db_append_recno_fcn)(DB *dbp, Dbt *data, db_recno_t recno)); -
When using the DB_APPEND option of the Db::put method, -it may be useful to modify the stored data based on the generated key. -If a callback method is specified using the -Db::set_append_recno method, it will be called after the record number -has been selected but before the data has been stored. -The callback function must return 0 on success and errno or -a value outside of the Berkeley DB error name space on failure. -
The called function must take three arguments: a reference to the -enclosing database handle, the data Dbt to be stored and the -selected record number. The called function may then modify the data -Dbt. -
The Db::set_append_recno interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_append_recno method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_bt_compare.html b/bdb/docs/api_cxx/db_set_bt_compare.html deleted file mode 100644 index 5ca95d40110..00000000000 --- a/bdb/docs/api_cxx/db_set_bt_compare.html +++ /dev/null @@ -1,109 +0,0 @@ - - - - -
-
-Db::set_bt_compare- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef int (*bt_compare_fcn_type)(DB *, const DBT *, const DBT *); -}; -int -Db::set_bt_compare(bt_compare_fcn_type bt_compare_fcn); -
Set the Btree key comparison function. The comparison function is -called when it is necessary to compare a key specified by the -application with a key currently stored in the tree. The first argument -to the comparison function is the Dbt representing the -application supplied key, the second is the current tree's key. -
The comparison function must return an integer value less than, equal -to, or greater than zero if the first key argument is considered to be -respectively less than, equal to, or greater than the second key -argument. In addition, the comparison function must cause the keys in -the database to be well-ordered. The comparison function -must correctly handle any key values used by the application (possibly -including zero-length keys). In addition, when Btree key prefix -comparison is being performed (see Db::set_bt_prefix for more -information), the comparison routine may be passed a prefix of any -database key. The data and size fields of the -Dbt are the only fields that may be used for the purposes of -this comparison. -
If no comparison function is specified, the keys are compared lexically, -with shorter keys collating before longer keys. The same comparison -method must be used each time a particular Btree is opened. -
The Db::set_bt_compare interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_bt_compare method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_bt_minkey.html b/bdb/docs/api_cxx/db_set_bt_minkey.html deleted file mode 100644 index c0c5aced12b..00000000000 --- a/bdb/docs/api_cxx/db_set_bt_minkey.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-Db::set_bt_minkey- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_bt_minkey(u_int32_t bt_minkey); -
Set the minimum number of keys that will be stored on any single -Btree page. -
This value is used to determine which keys will be stored on overflow -pages, i.e. if a key or data item is larger than the underlying database -page size divided by the bt_minkey value, it will be stored on -overflow pages instead of within the page itself. The bt_minkey -value specified must be at least 2; if bt_minkey is not explicitly -set, a value of 2 is used. -
The Db::set_bt_minkey interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_bt_minkey method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_bt_prefix.html b/bdb/docs/api_cxx/db_set_bt_prefix.html deleted file mode 100644 index ecf9495459a..00000000000 --- a/bdb/docs/api_cxx/db_set_bt_prefix.html +++ /dev/null @@ -1,110 +0,0 @@ - - - - -
-
-Db::set_bt_prefix- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef size_t (*bt_prefix_fcn_type)(DB *, const DBT *, const DBT *); -}; -int -Db::set_bt_prefix(bt_prefix_fcn_type bt_prefix_fcn); -
Set the Btree prefix function. The prefix function must return the -number of bytes of the second key argument that would be required by -the Btree key comparison function to determine the second key argument's -ordering relationship with respect to the first key argument. If the -two keys are equal, the key length should be returned. The prefix -function must correctly handle any key values used by the application -(possibly including zero-length keys). The data and -size fields of the Dbt are the only fields that may be -used for the purposes of this determination. -
The prefix function is used to determine the amount by which keys stored -on the Btree internal pages can be safely truncated without losing their -uniqueness. See the Btree -prefix comparison section of the Reference Guide for more details about -how this works. The usefulness of this is data dependent, but in some -data sets can produce significantly reduced tree sizes and search times. -
If no prefix function or key comparison function is specified by the -application, a default lexical comparison function is used as the prefix -function. If no prefix function is specified and a key comparison -function is specified, no prefix function is used. It is an error to -specify a prefix function without also specifying a key comparison -function. -
The Db::set_bt_prefix interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_bt_prefix method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_cachesize.html b/bdb/docs/api_cxx/db_set_cachesize.html deleted file mode 100644 index cc8e020cc30..00000000000 --- a/bdb/docs/api_cxx/db_set_cachesize.html +++ /dev/null @@ -1,108 +0,0 @@ - - - - - -
-
-Db::set_cachesize- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_cachesize(u_int32_t gbytes, u_int32_t bytes, int ncache); -
Set the size of the database's shared memory buffer pool, i.e., the cache, -to gbytes gigabytes plus bytes. The cache should be the -size of the normal working data set of the application, with some small -amount of additional memory for unusual situations. (Note, the working -set is not the same as the number of simultaneously referenced pages, and -should be quite a bit larger!) -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
As databases opened within Berkeley DB environments use the cache specified to -the environment, it is an error to attempt to set a cache in a database -created within an environment. -
The Db::set_cachesize interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_cachesize method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The specified cache size was impossibly small. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_dup_compare.html b/bdb/docs/api_cxx/db_set_dup_compare.html deleted file mode 100644 index 7cd09ec0cb1..00000000000 --- a/bdb/docs/api_cxx/db_set_dup_compare.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - -
-
-Db::set_dup_compare- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef int (*dup_compare_fcn_type)(DB *, const DBT *, const DBT *); -}; -int -Db::set_dup_compare(dup_compare_fcn_type dup_compare_fcn); -
Set the duplicate data item comparison function. The comparison function -is called when it is necessary to compare a data item specified by the -application with a data item currently stored in the tree. The first -argument to the comparison function is the Dbt representing the -application's data item, the second is the current tree's data item. -
The comparison function must return an integer value less than, equal -to, or greater than zero if the first data item argument is considered -to be respectively less than, equal to, or greater than the second data -item argument. In addition, the comparison function must cause the data -items in the set to be well-ordered. The comparison function -must correctly handle any data item values used by the application -(possibly including zero-length data items). The data and -size fields of the Dbt are the only fields that may be -used for the purposes of this comparison. -
If no comparison function is specified, the data items are compared -lexically, with shorter data items collating before longer data items. -The same duplicate data item comparison method must be used each time -a particular Btree is opened. -
The Db::set_dup_compare interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_dup_compare method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_errcall.html b/bdb/docs/api_cxx/db_set_errcall.html deleted file mode 100644 index 6cc5310eb50..00000000000 --- a/bdb/docs/api_cxx/db_set_errcall.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - -
-
-Db::set_errcall- |
-
-
- |
-#include <db_cxx.h> --void Db::set_errcall( - void (*db_errcall_fcn)(const char *errpfx, char *msg)); -
The Db::set_errcall method is used to enhance the mechanism for reporting error -messages to the application. In some cases, when an error occurs, Berkeley DB -will call db_errcall_fcn with additional error information. The -function must be defined with two arguments; the first will be the prefix -string (as previously set by Db::set_errpfx or -DbEnv::set_errpfx), the second will be the error message string. -It is up to the db_errcall_fcn method to display the error -message in an appropriate manner. -
Alternatively, you can use the DbEnv::set_error_stream method to display -the additional information via an output stream, or the Db::set_errfile -or DbEnv::set_errfile methods to display the additional information via a C -library FILE *. You should not mix these approaches. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
For Db handles opened inside of Berkeley DB environments, calling the -Db::set_errcall method affects the entire environment and is equivalent to calling -the DbEnv::set_errcall method. -
The Db::set_errcall interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_errfile.html b/bdb/docs/api_cxx/db_set_errfile.html deleted file mode 100644 index 50c6bebd1d8..00000000000 --- a/bdb/docs/api_cxx/db_set_errfile.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - -
-
-Db::set_errfile- |
-
-
- |
-#include <db_cxx.h> --void Db::set_errfile(FILE *errfile); -
The Db::set_errfile method is used to enhance the mechanism for reporting error -messages to the application by setting a C library FILE * to be used for -displaying additional Berkeley DB error messages. In some cases, when an error -occurs, Berkeley DB will output an additional error message to the specified -file reference. -
Alternatively, you can use the DbEnv::set_error_stream method to display -the additional information via an output stream, or the -DbEnv::set_errcall method to capture the additional error information in -a way that does not use either output streams or C library FILE *'s. You -should not mix these approaches. -
The error message will consist of the prefix string and a colon -(":") (if a prefix string was previously specified using -Db::set_errpfx or DbEnv::set_errpfx), an error string, and -a trailing <newline> character. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
For Db handles opened inside of Berkeley DB environments, calling the -Db::set_errfile method affects the entire environment and is equivalent to calling -the DbEnv::set_errfile method. -
The Db::set_errfile interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_errpfx.html b/bdb/docs/api_cxx/db_set_errpfx.html deleted file mode 100644 index 0baa3ba674c..00000000000 --- a/bdb/docs/api_cxx/db_set_errpfx.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-Db::set_errpfx- |
-
-
- |
-#include <db_cxx.h> --void Db::set_errpfx(const char *errpfx); -
Set the prefix string that appears before error messages issued by Berkeley DB. -
The Db::set_errpfx method does not copy the memory referenced by the -errpfx argument, rather, it maintains a reference to it. This -allows applications to modify the error message prefix at any time, -without repeatedly calling Db::set_errpfx, but means that the -memory must be maintained until the handle is closed. -
For Db handles opened inside of Berkeley DB environments, calling the -Db::set_errpfx method affects the entire environment and is equivalent to calling -the DbEnv::set_errpfx method. -
The Db::set_errpfx interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_feedback.html b/bdb/docs/api_cxx/db_set_feedback.html deleted file mode 100644 index 97a5a85b717..00000000000 --- a/bdb/docs/api_cxx/db_set_feedback.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - -
-
-Db::set_feedback- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_feedback( - void (*db_feedback_fcn)(DB *dbp, int opcode, int pct)); -
Some operations performed by the Berkeley DB library can take non-trivial -amounts of time. The Db::set_feedback method can be used by -applications to monitor progress within these operations. -
When an operation is likely to take a long time, Berkeley DB will call the -specified callback method. This method must be declared with -three arguments: the first will be a reference to the enclosing database -handle, the second a flag value, and the third the percent of the -operation that has been completed, specified as an integer value between -0 and 100. It is up to the callback method to display this -information in an appropriate manner. -
The opcode argument may take on any of the following values: -
The Db::set_feedback interface may be used to configure Berkeley DB at any time -during the life of the application. -
The Db::set_feedback method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_flags.html b/bdb/docs/api_cxx/db_set_flags.html deleted file mode 100644 index 059810357ec..00000000000 --- a/bdb/docs/api_cxx/db_set_flags.html +++ /dev/null @@ -1,183 +0,0 @@ - - - - -
-
-Db::set_flags- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_flags(u_int32_t flags); -
Calling Db::set_flags is additive, there is no way to clear flags. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The following flags may be specified for the Btree access method: -
Logical record numbers in Btree databases are mutable in the face of -record insertion or deletion. See the DB_RENUMBER flag in the Recno -access method information for further discussion. -
Maintaining record counts within a Btree introduces a serious point of -contention, namely the page locations where the record counts are stored. -In addition, the entire tree must be locked during both insertions and -deletions, effectively single-threading the tree for those operations. -Specifying DB_RECNUM can result in serious performance degradation for -some applications and data sets. -
It is an error to specify both DB_DUP and DB_RECNUM. -
The following flags may be specified for the Hash access method: -
There are no additional flags that may be specified for the Queue access -method. -
The following flags may be specified for the Recno access method: -
Using the Db::put or Dbc::put interfaces to create new -records will cause the creation of multiple records if the record number -is more than one greater than the largest record currently in the -database. For example, creating record 28, when record 25 was previously -the last record in the database, will create records 26 and 27 as well as -28. Attempts to retrieve records that were created in this manner will -result in an error return of DB_KEYEMPTY. -
If a created record is not at the end of the database, all records -following the new record will be automatically renumbered upward by 1. -For example, the creation of a new record numbered 8 causes records -numbered 8 and greater to be renumbered upward by 1. If a cursor was -positioned to record number 8 or greater before the insertion, it will be -shifted upward 1 logical record, continuing to reference the same record -as it did before. -
For these reasons, concurrent access to a Recno database with the -DB_RENUMBER flag specified may be largely meaningless, although -it is supported. -
The Db::set_flags interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_flags method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_h_ffactor.html b/bdb/docs/api_cxx/db_set_h_ffactor.html deleted file mode 100644 index fa7d4209e8e..00000000000 --- a/bdb/docs/api_cxx/db_set_h_ffactor.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - -
-
-Db::set_h_ffactor- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_h_ffactor(u_int32_t h_ffactor); -
Set the desired density within the hash table. -
The density is an approximation of the number of keys allowed to -accumulate in any one bucket, determining when the hash table grows or -shrinks. If you know the average sizes of the keys and data in your -dataset, setting the fill factor can enhance performance. A reasonable -rule computing fill factor is to set it to: -
-(pagesize - 32) / (average_key_size + average_data_size + 8)
If no value is specified, the fill factor will be selected dynamically as -pages are filled. -
The Db::set_h_ffactor interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_h_ffactor method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_h_hash.html b/bdb/docs/api_cxx/db_set_h_hash.html deleted file mode 100644 index 71808b081c8..00000000000 --- a/bdb/docs/api_cxx/db_set_h_hash.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - -
-
-Db::set_h_hash- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef u_int32_t (*h_hash_fcn_type) - (DB *, const void *bytes, u_int32_t length); -}; -int -Db::set_h_hash(h_hash_fcn_type h_hash_fcn); -
Set a user defined hash method; if no hash method is specified, a default -hash method is used. Since no hash method performs equally well on all -possible data, the user may find that the built-in hash method performs -poorly with a particular data set. User specified hash functions must -take a pointer to a byte string and a length as arguments and return a -value of type -u_int32_t. -The hash function must handle any key values used by the application -(possibly including zero-length keys). -
If a hash method is specified, Db::open will attempt to determine -if the hash method specified is the same as the one with which the database -was created, and will fail if it detects that it is not. -
The Db::set_h_hash interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_h_hash method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_h_nelem.html b/bdb/docs/api_cxx/db_set_h_nelem.html deleted file mode 100644 index 55698d45737..00000000000 --- a/bdb/docs/api_cxx/db_set_h_nelem.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-Db::set_h_nelem- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_h_nelem(u_int32_t h_nelem); -
Set an estimate of the final size of the hash table. -
If not set or set too low, hash tables will still expand gracefully -as keys are entered, although a slight performance degradation may be -noticed. -
The Db::set_h_nelem interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_h_nelem method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_lorder.html b/bdb/docs/api_cxx/db_set_lorder.html deleted file mode 100644 index f25779a252a..00000000000 --- a/bdb/docs/api_cxx/db_set_lorder.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - -
-
-Db::set_lorder- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_lorder(int lorder); -
Set the byte order for integers in the stored database metadata. The -number should represent the order as an integer, for example, big endian -order is the number 4,321, and little endian order is the number 1,234. -If lorder is not explicitly set, the host order of the machine -where the Berkeley DB library was compiled is used. -
The value of lorder is ignored except when databases are being -created. If a database already exists, the byte order it uses is -determined when the database is opened. -
The access methods provide no guarantees about the byte ordering of the -application data stored in the database, and applications are responsible -for maintaining any necessary ordering. -
The Db::set_lorder interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_lorder method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_malloc.html b/bdb/docs/api_cxx/db_set_malloc.html deleted file mode 100644 index e38092fcbeb..00000000000 --- a/bdb/docs/api_cxx/db_set_malloc.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - -
-
-Db::set_malloc- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -Db::set_malloc(db_malloc_fcn_type db_malloc); -
Set the allocation function used by the Db methods to allocate -memory in which to return key/data items to the application. -
The DB_DBT_MALLOC flag, when specified in the Dbt object, -will cause the Db methods to allocate and re-allocate memory which -then becomes the responsibility of the calling application. See Dbt -for more information. -
On systems where there may be multiple library versions of malloc (notably -Windows NT), specifying the DB_DBT_MALLOC flag will fail because -the Db library will allocate memory from a different heap than -the application will use to free it. To avoid this problem, the -Db::set_malloc method can be used to pass Berkeley DB a reference to the -application's allocation routine, in which case it will be used to -allocate the memory returned when the DB_DBT_MALLOC flag is set. -
The method specified must match the calling conventions of the -ANSI C X3.159-1989 (ANSI C) library routine of the same name. -
The Db::set_malloc interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_malloc method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_pagesize.html b/bdb/docs/api_cxx/db_set_pagesize.html deleted file mode 100644 index 114f0578aa7..00000000000 --- a/bdb/docs/api_cxx/db_set_pagesize.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-Db::set_pagesize- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_pagesize(u_int32_t pagesize); -
Set the size of the pages used to hold items in the database, in bytes. -The minimum page size is 512 bytes and the maximum page size is 64K bytes. -If the page size is not explicitly set, one is selected based on the -underlying filesystem I/O block size. The automatically selected size -has a lower limit of 512 bytes and an upper limit of 16K bytes. -
For information on tuning the Berkeley DB page size, see -Selecting a page size. -
The Db::set_pagesize interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_pagesize method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_paniccall.html b/bdb/docs/api_cxx/db_set_paniccall.html deleted file mode 100644 index 7cd08de4a53..00000000000 --- a/bdb/docs/api_cxx/db_set_paniccall.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - -
-
-Db::set_paniccall- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_paniccall( - void (*db_paniccall_fcn)(DbEnv *dbenv, int errval)); -
Errors can occur in the Berkeley DB library where the only solution is to shut -down the application and run recovery. (For example, if Berkeley DB is unable -to write log records to disk because there is insufficient disk space.) -In these cases, when the C++ error model has been configured so that the -individual Berkeley DB methods return error codes (see DbException for -more information), the value DB_RUNRECOVERY is returned by Berkeley DB -methods. -
In these cases, it is also often simpler to shut down the application when -such errors occur rather than attempting to gracefully return up the stack. -The Db::set_paniccall method is used to specify a method to be called when -DB_RUNRECOVERY is about to be returned from a Berkeley DB method. When -called, the dbenv argument will be a reference to the current -environment, and the errval argument is the error value that would -have been returned to the calling method. -
For Db handles opened inside of Berkeley DB environments, calling the -Db::set_paniccall method affects the entire environment and is equivalent to calling -the DbEnv::set_paniccall method. -
The Db::set_paniccall interface may be used to configure Berkeley DB at any time -during the life of the application. -
The Db::set_paniccall method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_q_extentsize.html b/bdb/docs/api_cxx/db_set_q_extentsize.html deleted file mode 100644 index d9c702196b7..00000000000 --- a/bdb/docs/api_cxx/db_set_q_extentsize.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-Db::set_q_extentsize- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_q_extentsize(u_int32_t extentsize); -
Set the size of the extents used to hold pages in a Queue database, -specified as a number of pages. Each extent is created as a separate -physical file. If no extent size is set, the default behavior is to -create only a single underlying database file. -
For information on tuning the extent size, see -Selecting a extent size. -
The Db::set_q_extentsize interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_q_extentsize method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_re_delim.html b/bdb/docs/api_cxx/db_set_re_delim.html deleted file mode 100644 index c88d6e89e06..00000000000 --- a/bdb/docs/api_cxx/db_set_re_delim.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-Db::set_re_delim- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_re_delim(int re_delim); -
Set the delimiting byte used to mark the end of a record in the backing -source file for the Recno access method. -
This byte is used for variable length records, if the re_source -file is specified. If the re_source file is specified and no -delimiting byte was specified, <newline> characters (i.e. -ASCII 0x0a) are interpreted as end-of-record markers. -
The Db::set_re_delim interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_re_delim method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_re_len.html b/bdb/docs/api_cxx/db_set_re_len.html deleted file mode 100644 index 7432ced166d..00000000000 --- a/bdb/docs/api_cxx/db_set_re_len.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - -
-
-Db::set_re_len- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_re_len(u_int32_t re_len); -
For the Queue access method, specify that the records are of length -re_len. -
For the Recno access method, specify that the records are fixed-length, -not byte delimited, and are of length re_len. -
Any records added to the database that are less than re_len bytes -long are automatically padded (see Db::set_re_pad for more -information). -
Any attempt to insert records into the database that are greater than -re_len bytes long will cause the call to fail immediately and -return an error. -
The Db::set_re_len interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_re_len method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_re_pad.html b/bdb/docs/api_cxx/db_set_re_pad.html deleted file mode 100644 index 5b9453d0db2..00000000000 --- a/bdb/docs/api_cxx/db_set_re_pad.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-Db::set_re_pad- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_re_pad(int re_pad); -
Set the padding character for short, fixed-length records for the Queue -and Recno access methods. -
If no pad character is specified, <space> characters (i.e., -ASCII 0x20) are used for padding. -
The Db::set_re_pad interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_re_pad method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_re_source.html b/bdb/docs/api_cxx/db_set_re_source.html deleted file mode 100644 index ea51dde6202..00000000000 --- a/bdb/docs/api_cxx/db_set_re_source.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - -
-
-Db::set_re_source- |
-
-
- |
-#include <db_cxx.h> --int -Db::set_re_source(char *re_source); -
Set the underlying source file for the Recno access method. The purpose -of the re_source value is to provide fast access and modification -to databases that are normally stored as flat text files. -
If the re_source field is set, it specifies an underlying flat -text database file that is read to initialize a transient record number -index. In the case of variable length records, the records are separated -as specified by Db::set_re_delim. For example, standard UNIX -byte stream files can be interpreted as a sequence of variable length -records separated by <newline> characters. -
In addition, when cached data would normally be written back to the -underlying database file (e.g., the Db::close or Db::sync -methods are called), the in-memory copy of the database will be written -back to the re_source file. -
By default, the backing source file is read lazily, i.e., records are not -read from the file until they are requested by the application. -If multiple processes (not threads) are accessing a Recno database -concurrently and either inserting or deleting records, the backing source -file must be read in its entirety before more than a single process -accesses the database, and only that process should specify the backing -source file as part of the Db::open call. See the DB_SNAPSHOT -flag for more information. -
Reading and writing the backing source file specified by re_source -cannot be transactionally protected because it involves filesystem -operations that are not part of the Db transaction methodology. -For this reason, if a temporary database is used to hold the records, -i.e., a NULL was specified as the file argument to Db::open, -it is possible to lose the contents of the re_source file, e.g., -if the system crashes at the right instant. -If a file is used to hold the database, i.e., a file name was specified -as the file argument to Db::open, normal database -recovery on that file can be used to prevent information loss, -although it is still possible that the contents of re_source -will be lost if the system crashes. -
The re_source file must already exist (but may be zero-length) when -Db::open is called. -
It is not an error to specify a read-only re_source file when -creating a database, nor is it an error to modify the resulting database. -However, any attempt to write the changes to the backing source file using -either the Db::sync or Db::close methods will fail, of course. -Specify the DB_NOSYNC flag to the Db::close method to stop it -from attempting to write the changes to the backing file, instead, they -will be silently discarded. -
For all of the above reasons, the re_source field is generally -used to specify databases that are read-only for Db applications, -and that are either generated on the fly by software tools, or modified -using a different mechanism, e.g., a text editor. -
The Db::set_re_source interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_re_source method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after Db::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_set_realloc.html b/bdb/docs/api_cxx/db_set_realloc.html deleted file mode 100644 index e163a889c33..00000000000 --- a/bdb/docs/api_cxx/db_set_realloc.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - -
-
-Db::set_realloc- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_realloc_fcn_type)(void *, size_t); -}; -int -Db::set_realloc(db_realloc_fcn_type db_realloc_fcn); -
Set the realloc function used by the Db methods to allocate memory -in which to return key/data items to the application. -
The DB_DBT_REALLOC flag, when specified in the Dbt object, -will cause the Db methods to allocate and re-allocate memory which -then becomes the responsibility of the calling application. See Dbt -for more information. -
On systems where there may be multiple library versions of realloc (notably -Windows NT), specifying the DB_DBT_REALLOC flag will fail because -the Db library will allocate memory from a different heap than -the application will use to free it. To avoid this problem, the -Db::set_realloc method can be used to pass Berkeley DB a reference to the -application's allocation routine, in which case it will be used to -allocate the memory returned when the DB_DBT_REALLOC flag is set. -
The method specified must match the calling conventions of the -ANSI C X3.159-1989 (ANSI C) library routine of the same name. -
The Db::set_realloc interface may only be used to configure Berkeley DB before -the Db::open interface is called. -
The Db::set_realloc method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_stat.html b/bdb/docs/api_cxx/db_stat.html deleted file mode 100644 index 4245fd91704..00000000000 --- a/bdb/docs/api_cxx/db_stat.html +++ /dev/null @@ -1,201 +0,0 @@ - - - - -
-
-Db::stat- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -Db::stat(void *sp, db_malloc_fcn_type db_malloc, u_int32_t flags); -
The Db::stat method creates a statistical structure and -copies a pointer to it into user-specified memory locations. -Specifically, if sp is non-NULL, a pointer to the statistics -for the database are copied into the memory location it references. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The flags parameter must be set to 0 or the following value: -
This option is only available for Recno databases, or Btree databases -where the underlying database was created with the DB_RECNUM -flag. -
The Db::stat method may access all of the pages in the database, -incurring a severe performance penalty as well as possibly flushing the -underlying buffer pool. -
In the presence of multiple threads or processes accessing an active -database, the information returned by Db::stat may be out-of-date. -
If the database was not opened readonly and the DB_CACHED_COUNTS -flag was not specified, the cached key and record numbers will be updated -after the statistical information has been gathered. -
The Db::stat method cannot be transaction protected. For this reason, -it should be called in a thread of control that has no open cursors or -active transactions. -
The Db::stat method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
In the case of a Hash database, -the statistics are stored in a structure of type DB_HASH_STAT. The -following fields will be filled in: -
In the case of a Btree or Recno database, -the statistics are stored in a structure of type DB_BTREE_STAT. The -following fields will be filled in: -
For the Recno Access Method, the number of records in the database. -
For the Recno Access Method, the number of records in the database. If -the database has been configured to not re-number records during -deletion, the number of records will only reflect undeleted records. -
In the case of a Queue database, -the statistics are stored in a structure of type DB_QUEUE_STAT. The -following fields will be filled in: -
The Db::stat method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::stat method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::stat method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_sync.html b/bdb/docs/api_cxx/db_sync.html deleted file mode 100644 index 170d99127f5..00000000000 --- a/bdb/docs/api_cxx/db_sync.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - -
-
-Db::sync- |
-
-
- |
-#include <db_cxx.h> --int -Db::sync(u_int32_t flags); -
The Db::sync method flushes any cached information to disk. -
If the database is in memory only, the Db::sync method has no effect and -will always succeed. -
The flags parameter is currently unused, and must be set to 0. -
See Db::close for a discussion of Berkeley DB and cached data. -
The Db::sync method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if the underlying database still has -dirty pages in the cache. (The only reason to return -DB_INCOMPLETE is if another thread of control was writing pages -in the underlying database file at the same time as the -Db::sync method was being called. For this reason, a return of -DB_INCOMPLETE can normally be ignored, or, in cases where it is -a possible return value, there may be no reason to call -Db::sync.) -
The Db::sync method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::sync method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::sync method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_upgrade.html b/bdb/docs/api_cxx/db_upgrade.html deleted file mode 100644 index 8cbc3561fe3..00000000000 --- a/bdb/docs/api_cxx/db_upgrade.html +++ /dev/null @@ -1,135 +0,0 @@ - - - - -
-
-Db::upgrade- |
-
-
- |
-#include <db_cxx.h> --int -Db::upgrade(const char *file, u_int32_t flags); -
The Db::upgrade method upgrades all of the databases included in the -file file, if necessary. If no upgrade is necessary, -Db::upgrade always returns success. -
Database upgrades are done in place and are destructive, e.g., if pages -need to be allocated and no disk space is available, the database may be -left corrupted. Backups should be made before databases are upgraded. -See Upgrading databases for more -information. -
Unlike all other database operations, Db::upgrade may only be done -on a system with the same byte-order as the database. -
The flags parameter must be set to 0 or one of the following -values: -
As part of the upgrade from the Berkeley DB 3.0 release to the 3.1 release, the -on-disk format of duplicate data items changed. To correctly upgrade the -format requires applications specify if duplicate data items in the -database are sorted or not. Specifying the DB_DUPSORT flag -informs Db::upgrade that the duplicates are sorted, otherwise they -are assumed to be unsorted. Incorrectly specifying the value of this flag -may lead to database corruption. -
Further, because the Db::upgrade method upgrades a physical file -(including all of the databases it contains), it is not possible to use -Db::upgrade to upgrade files where some of the databases it -includes have sorted duplicate data items and some of the databases it -includes have unsorted duplicate data items. If the file does not have -more than a single database, or the databases do not support duplicate -data items, or all of the databases that support duplicate data items -support the same style of duplicates (either sorted or unsorted), -Db::upgrade will work correctly as long as the DB_DUPSORT -flag is correctly specified. Otherwise, the file cannot be upgraded using -Db::upgrade, and must be upgraded manually by dumping and -re-loading the databases. -
The Db::upgrade method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Db::upgrade method may fail and throw an exception or return a non-zero error for the following conditions: -
The database is not in the same byte-order as the system. -
The Db::upgrade method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::upgrade method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/db_verify.html b/bdb/docs/api_cxx/db_verify.html deleted file mode 100644 index 7e742af4c50..00000000000 --- a/bdb/docs/api_cxx/db_verify.html +++ /dev/null @@ -1,150 +0,0 @@ - - - - -
-
-Db::verify- |
-
-
- |
-#include <db_cxx.h> --int -Db::verify(const char *file, - const char *database, ostream *outfile, u_int32_t flags); -
The Db::verify method verifies the integrity of all databases in the -file specified by the file argument, and optionally outputs the databases' -key/data pairs to a file stream. -
The flags parameter must be set to 0 or one of the following -values: -
Because the key/data pairs are output in page order as opposed to the sort -order used by db_dump, using Db::verify to dump key/data -pairs normally produces less than optimal loads for Btree databases. -
In addition, the following flags may be set by bitwise inclusively OR'ing them into the -flags parameter: -
The Db::verify method normally verifies that btree keys and duplicate -items are correctly sorted and hash keys are correctly hashed. If the -file being verified contains multiple databases using differing sorting -or hashing algorithms, some of them must necessarily fail database -verification as only one sort order or hash function can be specified -before Db::verify is called. To verify files with multiple -databases having differing sorting orders or hashing functions, first -perform verification of the file as a whole by using the -DB_NOORDERCHK flag, and then individually verify the sort order -and hashing function for each database in the file using the -DB_ORDERCHKONLY flag. -
When this flag is specified, a database argument should also be -specified, indicating the database in the physical file which is to be -checked. This flag is only safe to use on databases that have already -successfully been verified using Db::verify with the -DB_NOORDERCHK flag set. -
The database argument must be set to NULL except when the -DB_ORDERCHKONLY flag is set. -
The Db::verify method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and DB_VERIFY_BAD if a database is corrupted. When the -DB_SALVAGE flag is specified, the DB_VERIFY_BAD return -means that all key/data pairs in the file may not have been successfully -output. -
The Db::verify method may fail and throw an exception or return a non-zero error for the following conditions: -
The Db::verify method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db::verify method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_class.html b/bdb/docs/api_cxx/dbc_class.html deleted file mode 100644 index ac8081d4ab3..00000000000 --- a/bdb/docs/api_cxx/dbc_class.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - -
-
-Dbc- |
-
-
- |
-#include <db_cxx.h> --class Dbc { ... }; -
This manual page describes the specific details of the Dbc class, -which provides cursor support for the access methods in Db. -
The Dbc functions are the library interface supporting sequential -access to the records stored by the access methods of the Berkeley DB library. -Cursors are created by calling the Db::cursor method which returns a -pointer to a Dbc object. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_close.html b/bdb/docs/api_cxx/dbc_close.html deleted file mode 100644 index 881bc3f7de8..00000000000 --- a/bdb/docs/api_cxx/dbc_close.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-Dbc::close- |
-
-
- |
-#include <db_cxx.h> --int -Dbc::close(void); -
The Dbc::close method discards the cursor. -
It is possible for the Dbc::close method to return -DB_LOCK_DEADLOCK, signaling that any enclosing transaction should -be aborted. If the application is already intending to abort the -transaction, this error should be ignored, and the application should -proceed. -
Once Dbc::close has been called, regardless of its return, the -cursor handle may not be used again. -
The Dbc::close method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Dbc::close method may fail and throw an exception or return a non-zero error for the following conditions: -
The cursor was previously closed. -
The Dbc::close method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc::close method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_count.html b/bdb/docs/api_cxx/dbc_count.html deleted file mode 100644 index be8f6b8e601..00000000000 --- a/bdb/docs/api_cxx/dbc_count.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-Dbc::count- |
-
-
- |
-#include <db_cxx.h> --int -Dbc::count(db_recno_t *countp, u_int32_t flags); -
The Dbc::count method returns a count of the number of duplicate data -items for the key referenced by the -cursor into the memory location referenced by countp. -If the underlying database does not support duplicate data items the call -will still succeed and a count of 1 will be returned. -
The flags parameter is currently unused, and must be set to 0. -
If the cursor argument is not yet initialized, the Dbc::count method either returns EINVAL or throws an exception that encapsulates EINVAL. -
Otherwise, the Dbc::count method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Dbc::count method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc::count method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_del.html b/bdb/docs/api_cxx/dbc_del.html deleted file mode 100644 index 18f6959a8b3..00000000000 --- a/bdb/docs/api_cxx/dbc_del.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-Dbc::del- |
-
-
- |
-#include <db_cxx.h> --int -Dbc::del(u_int32_t flags); -
The Dbc::del method deletes the key/data pair currently referenced by -the cursor. -
The flags parameter is currently unused, and must be set to 0. -
The cursor position is unchanged after a delete, and subsequent calls to -cursor functions expecting the cursor to reference an existing key will -fail. -
If the element has already been deleted, Dbc::del will return -DB_KEYEMPTY. -
If the cursor is not yet initialized, the Dbc::del method either returns EINVAL or throws an exception that encapsulates EINVAL. -
Otherwise, the Dbc::del method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Dbc::del method may fail and throw an exception or return a non-zero error for the following conditions: -
The Dbc::del method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc::del method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_dup.html b/bdb/docs/api_cxx/dbc_dup.html deleted file mode 100644 index 5dec52e46a6..00000000000 --- a/bdb/docs/api_cxx/dbc_dup.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-Dbc::dup- |
-
-
- |
-#include <db_cxx.h> --int -Dbc::dup(Dbc **cursorp, u_int32_t flags); -
The Dbc::dup method creates a new cursor that uses the same transaction -and locker ID as the original cursor. This is useful when an application -is using locking and requires two or more cursors in the same thread of -control. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
When using the Berkeley DB Concurrent Data Store product, there can be only one active write cursor -at a time. For this reason, attempting to duplicate a cursor for which -the DB_WRITECURSOR flag was specified during creation will return -an error. -
If the cursor argument is not yet initialized, the Dbc::dup method either returns EINVAL or throws an exception that encapsulates EINVAL. -
Otherwise, the Dbc::dup method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The Dbc::dup method may fail and throw an exception or return a non-zero error for the following conditions: -
The cursor argument was created using the -DB_WRITECURSOR flag in the Berkeley DB Concurrent Data Store product. -
The Dbc::dup method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc::dup method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_get.html b/bdb/docs/api_cxx/dbc_get.html deleted file mode 100644 index d42a194e514..00000000000 --- a/bdb/docs/api_cxx/dbc_get.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - -
-
-Dbc::get- |
-
-
- |
-#include <db_cxx.h> --int -Dbc::get(Dbt *key, Dbt *data, u_int32_t flags); -
The Dbc::get method retrieves key/data pairs from the database. The -address and length of the key -are returned in the object referenced by key (except for the case -of the DB_SET flag where the key object is unchanged), -and the address and length of -the data are returned in the object referenced by data. -
Modifications to the database during a sequential scan will be reflected -in the scan, i.e. records inserted behind a cursor will not be returned -while records inserted in front of a cursor will be returned. -
In Queue and Recno databases, missing entries (i.e., entries that were -never explicitly created or that were created and then deleted), will be -skipped during a sequential scan. -
If multiple threads or processes insert items into the same database file -without using locking, the results are undefined. -For more detail, -see Cursor stability. -
The flags parameter must be set to one of the following values: -
If the cursor key/data pair was deleted, Dbc::get will return -DB_KEYEMPTY. -
If the cursor is not yet initialized, the Dbc::get method either returns EINVAL or throws an exception that encapsulates EINVAL. -
If the database is a Queue or Recno database, Dbc::get using the -DB_FIRST (DB_LAST) flags will ignore any keys that exist -but were never explicitly created by the application or were created and -later deleted. -
If the database is empty, Dbc::get will return DB_NOTFOUND. -
For DB_GET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM -flag. -
For DB_JOIN_ITEM to be specified, the underlying cursor must have -been returned from the Db::join method. -
If the database is a Queue or Recno database, Dbc::get using the -DB_NEXT (DB_PREV) flag will skip any keys that exist but -were never explicitly created by the application or were created and later -deleted. -
If the cursor is already on the last (first) record in the database, -Dbc::get will return DB_NOTFOUND. -
If the cursor is not yet initialized, the Dbc::get method either returns EINVAL or throws an exception that encapsulates EINVAL. -
If the database is a Queue or Recno database, Dbc::get using the -DB_NEXT_NODUP (DB_PREV_NODUP) flags will ignore any keys -that exist but were never explicitly created by the application or were -created and later deleted. -
If no non-duplicate key/data pairs occur after (before) the cursor -position in the database, Dbc::get will return DB_NOTFOUND. -
In the presence of duplicate key values, Dbc::get will return the -first data item for the given key. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -Dbc::get will return DB_KEYEMPTY. -
If no matching keys are found, Dbc::get will return -DB_NOTFOUND. -
For DB_SET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM -flag. -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
Otherwise, the Dbc::get method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
If Dbc::get fails for any reason, the state of the cursor will be -unchanged. -
The Dbc::get method may fail and throw an exception or return a non-zero error for the following conditions: -
The specified cursor was not currently initialized. -
The Dbc::get method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc::get method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbc_put.html b/bdb/docs/api_cxx/dbc_put.html deleted file mode 100644 index 05a95cd36bc..00000000000 --- a/bdb/docs/api_cxx/dbc_put.html +++ /dev/null @@ -1,158 +0,0 @@ - - - - -
-
-Dbc::put- |
-
-
- |
-#include <db_cxx.h> --int -Dbc::put(Dbt *key, Dbt *data, u_int32_t flags); -
The Dbc::put method stores key/data pairs into the database. -
The flags parameter must be set to one of the following values: -
In the case of the Recno access method, it is an error to specify -DB_AFTER if the underlying Recno database was not created with -the DB_RENUMBER flag. If the DB_RENUMBER flag was -specified, a new key is created, all records after the inserted item -are automatically renumbered, and the key of the new record is returned -in the structure referenced by the parameter key. The initial -value of the key parameter is ignored. See Db::open -for more information. -
The DB_AFTER flag may not be specified to the Queue access method. -
If the current cursor record has already been deleted and the underlying -access method is Hash, Dbc::put will return DB_NOTFOUND. -If the underlying access method is Btree or Recno, the operation will -succeed. -
If the cursor is not yet initialized or a duplicate sort function has been -specified, the Dbc::put function will return EINVAL. -
In the case of the Recno access method, it is an error to specify -DB_BEFORE if the underlying Recno database was not created with -the DB_RENUMBER flag. If the DB_RENUMBER flag was -specified, a new key is created, the current record and all records -after it are automatically renumbered, and the key of the new record is -returned in the structure referenced by the parameter key. The -initial value of the key parameter is ignored. See -Db::open for more information. -
The DB_BEFORE flag may not be specified to the Queue access method. -
If the current cursor record has already been deleted and the underlying -access method is Hash, Dbc::put will return DB_NOTFOUND. -If the underlying access method is Btree or Recno, the operation will -succeed. -
If the cursor is not yet initialized or a duplicate sort function has been -specified, Dbc::put will return EINVAL. -
If a duplicate sort function has been specified and the data item of the -current referenced key/data pair does not compare equally to the data -parameter, Dbc::put will return EINVAL. -
If the current cursor record has already been deleted and the underlying -access method is Hash, Dbc::put will return DB_NOTFOUND. -If the underlying access method is Btree, Queue or Recno, the operation -will succeed. -
If the cursor is not yet initialized, Dbc::put will return EINVAL. -
If the underlying database supports duplicate data items, and if the -key already exists in the database and a duplicate sort function has -been specified, the inserted data item is added in its sorted location. -If the key already exists in the database and no duplicate sort function -has been specified, the inserted data item is added as the first of the -data items for that key. -
The DB_KEYFIRST flag may not be specified to the Queue or Recno -access methods. -
If the underlying database supports duplicate data items, and if the -key already exists in the database and a duplicate sort function has -been specified, the inserted data item is added in its sorted location. -If the key already exists in the database, and no duplicate sort -function has been specified, the inserted data item is added as the last -of the data items for that key. -
The DB_KEYLAST flag may not be specified to the Queue or Recno -access methods. -
The DB_NODUPDATA flag may not be specified to the Queue or Recno -access methods. -
Otherwise, the Dbc::put method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
If Dbc::put fails for any reason, the state of the cursor will be -unchanged. If Dbc::put succeeds and an item is inserted into the -database, the cursor is always positioned to reference the newly inserted -item. -
The Dbc::put method may fail and throw an exception or return a non-zero error for the following conditions: -
The DB_BEFORE or DB_AFTER flags were specified, and the -underlying access method is Queue. -
An attempt was made to add a record to a fixed-length database that was too -large to fit. -
The Dbc::put method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc::put method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbenv_class.html b/bdb/docs/api_cxx/dbenv_class.html deleted file mode 100644 index 1c59dcbf1a1..00000000000 --- a/bdb/docs/api_cxx/dbenv_class.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-DbEnv- |
-
-
- |
-#include <db_cxx.h> --class DbEnv { -public: - DbEnv(u_int32 flags); - ~DbEnv(); - ... -}; -
This manual page describes the specific details of the DbEnv -class, which is the center of the Berkeley DB environment. -
The following flags value may be specified: -
The DB_CLIENT flag indicates to the system that this environment -is remote on a server. The use of this flag causes the environment -methods to use functions that call a server instead of local functions. -Prior to making any environment or database method calls, the -application must call the DbEnv::set_server function to establish -the connection to the server. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/dbt_class.html b/bdb/docs/api_cxx/dbt_class.html deleted file mode 100644 index 24d18c60e50..00000000000 --- a/bdb/docs/api_cxx/dbt_class.html +++ /dev/null @@ -1,230 +0,0 @@ - - - - -
-
-Dbt- |
-
-
- |
-#include <db_cxx.h> --class Dbt { -public: - void *get_data() const; - void set_data(void *); -
- u_int32_t get_size() const; - void set_size(u_int32_t); -
- u_int32_t get_ulen() const; - void set_ulen(u_int32_t); -
- u_int32_t get_dlen() const; - void set_dlen(u_int32_t); -
- u_int32_t get_doff() const; - void set_doff(u_int32_t); -
- u_int32_t get_flags() const; - void set_flags(u_int32_t); -
- Dbt(void *data, size_t size); - Dbt(); - Dbt(const Dbt &); - Dbt &operator = (const Dbt &); - ~Dbt(); -}; -
This manual page describes the specific details of the Dbt class, -used to encode keys and data items in a database. - -
Storage and retrieval for the Db access methods are based on -key/data pairs. Both key and data items are represented by Dbt -objects. Key and data byte strings may reference strings of zero length -up to strings of essentially unlimited length. See -Database limits for more -information. -
The Dbt class provides simple access to an underlying data structure, -whose elements can be examined or changed using the set_ or -get_ methods. The remainder of the manual page sometimes refers -to these accesses using the underlying name, e.g., simply ulen -instead of Dbt::get_ulen and Dbt::set_ulen. -Dbt can be subclassed, providing a way to associate -with it additional data, or references to other structures. -
The constructors set all elements of the underlying structure to zero. -The constructor with two arguments has the effect of setting all elements -to zero except for the specified data and size elements. -
In the case where the flags structure element is 0, when the -application is providing Berkeley DB a key or data item to store into the -database, Berkeley DB expects the data object to point to a byte string -of size bytes. When returning a key/data item to the application, -Berkeley DB will store into the data object a pointer to a byte string -of size bytes, and the memory referenced by the pointer will be -allocated and managed by Berkeley DB. -
The elements of the structure underlying the Dbt class are defined as follows: -
Note that applications can determine the length of a record by setting -the ulen to 0 and checking the return value found in size. -See the DB_DBT_USERMEM flag for more information. -
This element is accessed using -Dbt::get_ulen and Dbt::set_ulen. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
It is an error to specify more than one of DB_DBT_MALLOC, -DB_DBT_REALLOC and DB_DBT_USERMEM. -
It is an error to specify more than one of DB_DBT_MALLOC, -DB_DBT_REALLOC and DB_DBT_USERMEM. -
It is an error to specify more than one of DB_DBT_MALLOC, -DB_DBT_REALLOC and DB_DBT_USERMEM. -
If DB_DBT_MALLOC or DB_DBT_REALLOC is specified, Berkeley DB -allocates a properly sized byte array to contain the data. This can be -convenient if you know little about the nature of the data, specifically -the size of data in the database. However, if your application makes -repeated calls to retrieve keys or data, you may notice increased garbage -collection due to this allocation. If you know the maximum size of data -you are retrieving, you might decrease the memory burden and speed your -application by allocating your own byte array and using -DB_DBT_USERMEM. Even if you don't know the maximum size, you can -use this option and reallocate your array whenever your retrieval API call -returns an ENOMEM error, or throws an exception encapsulating an ENOMEM. -
For example, if the data portion of a retrieved record was 100 bytes, -and a partial retrieval was done using a Dbt having a dlen -field of 20 and a doff field of 85, the get call would succeed, -the data field would reference the last 15 bytes of the record, -and the size field would be set to 15. -
If the calling application is doing a put, the dlen bytes starting -doff bytes from the beginning of the specified key's data record -are replaced by the data specified by the data and size -objects. -If dlen is smaller than size, the record will grow, and if -dlen is larger than size, the record will shrink. -If the specified bytes do not exist, the record will be extended using nul -bytes as necessary, and the put call will succeed. -
It is an error to attempt a partial put using the Db::put -method in a database that supports duplicate records. -Partial puts in databases supporting duplicate records must be done -using a Dbc method. -
It is an error to attempt a partial put with differing dlen and -size values in Queue or Recno databases with fixed-length records. -
For example, if the data portion of a retrieved record was 100 bytes, -and a partial put was done using a Dbt having a dlen -field of 20, a doff field of 85, and a size field of 30, -the resulting record would be 115 bytes in length, where the last 30 -bytes would be those specified by the put call. -
When using the non-cursor Berkeley DB calls to retrieve key/data items (e.g., -Db::get), the memory referenced by the pointer stored into the -Dbt is only valid until the next call to Berkeley DB using the -Db handle returned by Db::open. (This includes -any use of the returned Db handle, including by another -thread of control within the process. For this reason, when multiple -threads are using the returned DB handle concurrently, one of the -DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM -flags must be specified for any non-cursor Dbt used for key or -data retrieval.) -
When using the cursor Berkeley DB calls to retrieve key/data items (e.g., -Dbc::get), the memory referenced by the pointer into the -Dbt is only valid until the next call to Berkeley DB using the -Dbc handle returned by Db::cursor. - -
The Berkeley DB access methods provide no guarantees about key/data byte string -alignment, and applications are responsible for arranging any necessary -alignment. The DB_DBT_MALLOC, DB_DBT_REALLOC and -DB_DBT_USERMEM flags may be used to store returned items in memory -of arbitrary alignment. - -
In all cases for the Queue and Recno access methods, and when calling the -Db::get and Dbc::get functions with the -DB_SET_RECNO flag specified, the data -field of the key must be a pointer to a memory location of type -db_recno_t, as typedef'd in the #include <db_cxx.h> include file. -This type is a 32-bit unsigned type, -(which limits the number of logical records in a Queue or Recno database, -and the maximum logical record which may be directly retrieved from a -Btree database, to 4,294,967,296). The size field of the key -should be the size of that type, i.e., -in the C programming language, sizeof(db_recno_t). -
Logical record numbers are 1-based, not 0-based, i.e., the first record -in the database is record number 1. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_close.html b/bdb/docs/api_cxx/env_close.html deleted file mode 100644 index fc1ae2573a4..00000000000 --- a/bdb/docs/api_cxx/env_close.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-DbEnv::close- |
-
-
- |
-#include <db_cxx.h> --DbEnv::close(u_int32_t flags); -
The DbEnv::close method closes the Berkeley DB environment, freeing any -allocated resources and closing any underlying subsystems. -
Calling DbEnv::close does not imply closing any databases that were -opened in the environment. -
The flags parameter is currently unused, and must be set to 0. -
Where the environment was initialized with the DB_INIT_LOCK flag, -calling DbEnv::close does not release any locks still held by the -closing process, providing functionality for long-lived locks. -Processes that wish to have all their locks -released can do so by issuing the appropriate DbEnv::lock_vec call. -
Where the environment was initialized with the DB_INIT_MPOOL -flag, calling DbEnv::close implies calls to DbMpoolFile::close for -any remaining open files in the memory pool that were returned to this -process by calls to DbMpoolFile::open. It does not imply a call to -DbMpoolFile::sync for those files. -
Where the environment was initialized with the DB_INIT_TXN flag, -calling DbEnv::close aborts any uncommitted transactions. -(Applications are should not depend on this behavior. If the process' has -already closed a database handle which is necessary to abort an -uncommitted transaction, the Berkeley DB environment must then require that -recovery be run before further operations are done, since once a -transaction exists that cannot be committed or aborted, no future -checkpoint can ever succeed.) -
In multi-threaded applications, only a single thread may call -DbEnv::close. -
Once DbEnv::close has been called, regardless of its return, -the Berkeley DB environment handle may not be accessed again. -
The DbEnv::close method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::close method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::close method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_open.html b/bdb/docs/api_cxx/env_open.html deleted file mode 100644 index 53c9908dcb8..00000000000 --- a/bdb/docs/api_cxx/env_open.html +++ /dev/null @@ -1,209 +0,0 @@ - - - - -
-
-DbEnv::open- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::open(const char *db_home, u_int32_t flags, int mode); -
The DbEnv::open method is the interface for opening the Berkeley DB -environment. It provides a structure for creating a consistent -environment for processes using one or more of the features of Berkeley DB. -
The db_home argument to DbEnv::open (and file name -resolution in general) is described in -Berkeley DB File Naming. -
The flags argument specifies the subsystems that are initialized -and how the application's environment affects Berkeley DB file naming, among -other things. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
As there are a large number of flags that can be specified, they have been -grouped together by functionality. The first group of flags indicate -which of the Berkeley DB subsystems should be initialized: -
Access method calls are largely unchanged when using this flag, although -any cursors through which update operations (e.g., Dbc::put, -Dbc::del) will be made must have the DB_WRITECURSOR value -set in the flags parameter to the cursor call that creates the cursor. -See Db::cursor for more information. -
The log is stored in one or more files in the environment directory. -Each file is named using the format log.NNNNNNNNNN, where -NNNNNNNNNN is the sequence number of the file within the log. -For further information, see -Log File Limits. -
If the log region is being created and log files are already present, the -log files are reviewed and subsequent log writes are appended -to the end of the log, rather than overwriting current log entries. -
The second group of flags govern what recovery, if any, is performed when -the environment is initialized: -
A standard part of the recovery process is to remove the existing Berkeley DB -environment and create a new one in which to perform recovery. If the -thread of control performing recovery does not specify the correct region -initialization information (e.g., the correct memory pool cache size), -the result can be an application running in an environment with incorrect -cache and other subsystem sizes. For this reason, the thread of control -performing recovery should either specify correct configuration -information before calling the DbEnv::open method, or it should remove -the environment after recovery is completed, leaving creation of the -correctly sized environment to a subsequent call to DbEnv::open. -
All Berkeley DB recovery processing must be single-threaded, that is, only a -single thread of control may perform recovery or access a Berkeley DB -environment while recovery is being performed. As it is not an error to -specify DB_RECOVER for an environment for which no recovery is -required, it is reasonable programming practice for the thread of control -responsible for performing recovery and creating the environment to always -specify the DB_RECOVER flag during startup. -
The DbEnv::open function returns successfully if DB_RECOVER -or DB_RECOVER_FATAL is specified and no log files exist, so it is -necessary to ensure all necessary log files are present before running -recovery. For further information, consult db_archive and -db_recover. -
The third group of flags govern file naming extensions in the environment: -
Finally, there are a few additional, unrelated flags: -
This flag should not be specified if more than a single process is -accessing the environment, as it is likely to cause database corruption -and unpredictable behavior, e.g., if both a server application and the -Berkeley DB utility db_stat will access the environment, the -DB_PRIVATE flag should not be specified. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by Berkeley DB -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
The DbEnv::open method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::open method may fail and throw an exception or return a non-zero error for the following conditions: -
-The DB_THREAD flag was specified and spinlocks are not -implemented for this architecture. -
The DB_HOME or TMPDIR environment variables were set but empty. -
An incorrectly formatted NAME VALUE entry or line was found. -
The DbEnv::open method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::open method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_remove.html b/bdb/docs/api_cxx/env_remove.html deleted file mode 100644 index 58c3ff5de0c..00000000000 --- a/bdb/docs/api_cxx/env_remove.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - -
-
-DbEnv::remove- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::remove(const char *db_home, u_int32_t flags); -
The DbEnv::remove method destroys a Berkeley DB environment, if it is not -currently in use. The environment regions, including any backing files, -are removed. Any log or database files and the environment directory are -not removed. -
The db_home argument to DbEnv::remove is described in -Berkeley DB File Naming. -
If there are processes that have called DbEnv::open without -calling DbEnv::close (i.e., there are processes currently using -the environment), DbEnv::remove will fail without further action, -unless the DB_FORCE flag is set, in which case -DbEnv::remove will attempt to remove the environment regardless -of any processes still using it. -
The result of attempting to forcibly destroy the environment when it is -in use is unspecified. Processes using an environment often maintain open -file descriptors for shared regions within it. On UNIX systems, the -environment removal will usually succeed and processes that have already -joined the region will continue to run in that region without change, -however processes attempting to join the environment will either fail or -create new regions. On other systems (e.g., Windows/NT), where the -unlink(2) system call will fail if any process has an open -file descriptor for the file, the region removal will fail. -
Calling DbEnv::remove should not be necessary for most applications, -as the Berkeley DB environment is cleaned up as part of normal database recovery -procedures, however, applications may wish to call DbEnv::remove -as part of application shutdown to free up system resources. -Specifically, when the DB_SYSTEM_MEM flag was specified to -DbEnv::open, it may be useful to call DbEnv::remove in order -to release system shared memory segments that have been allocated. -
In the case of catastrophic or system failure, database recovery must be -performed (see db_recover), or the DB_RECOVER and -DB_RECOVER_FATAL flags to DbEnv::open must be specified -when the environment is re-opened. Alternatively, if recovery is not -required because no database state is maintained across failures, and -the DB_SYSTEM_MEM flag was not specified when the environment -was created, it is possible to clean up an environment by removing all -of the files in the environment directory that begin with the string -prefix "__db", as no backing files are created in any other directory. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
In multi-threaded applications, only a single thread may call -DbEnv::remove. -
A DbEnv handle which has already been used to open an -environment should not be used to call the DbEnv::remove method, a new -DbEnv handle should be created for that purpose. -
Once DbEnv::remove has been called, regardless of its return, -the Berkeley DB environment handle may not be accessed again. -
The DbEnv::remove method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::remove method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::remove method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_cachesize.html b/bdb/docs/api_cxx/env_set_cachesize.html deleted file mode 100644 index 57ad573cb3f..00000000000 --- a/bdb/docs/api_cxx/env_set_cachesize.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - -
-
-DbEnv::set_cachesize- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_cachesize(u_int32_t gbytes, u_int32_t bytes, int ncache); -
Set the size of the database's shared memory buffer pool, i.e., the cache, -to gbytes gigabytes plus bytes. The cache should be the -size of the normal working data set of the application, with some small -amount of additional memory for unusual situations. (Note, the working -set is not the same as the number of simultaneously referenced pages, and -should be quite a bit larger!) -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
The DbEnv::set_cachesize interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_cachesize method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's cache size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_cachesize", one or more whitespace characters, -and the three arguments specified to this interface, separated by whitespace -characters, for example, "set_cachesize 1 500 2". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
The specified cache size was impossibly small. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_data_dir.html b/bdb/docs/api_cxx/env_set_data_dir.html deleted file mode 100644 index 7c8bd44ff3d..00000000000 --- a/bdb/docs/api_cxx/env_set_data_dir.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - -
-
-DbEnv::set_data_dir- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_data_dir(const char *dir); -
Set the path of a directory to be used as the location of the access -method database files. Paths specified to the Db::open function -will be searched relative to this path. Paths set using this interface -are additive, and specifying more than one will result in each specified -directory being searched for database files. If any directories are -specified, created database files will always be created in the first path -specified. -
If no database directories are specified, database files can only exist -in the environment home directory. See Berkeley DB File Naming for more information. -
For the greatest degree of recoverability from system or application -failure, database files and log files should be located on separate -physical devices. -
The DbEnv::set_data_dir interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_data_dir method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's data directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_data_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_errcall.html b/bdb/docs/api_cxx/env_set_errcall.html deleted file mode 100644 index 8c59632c684..00000000000 --- a/bdb/docs/api_cxx/env_set_errcall.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - -
-
-DbEnv::set_errcall- |
-
-
- |
-#include <db_cxx.h> --void DbEnv::set_errcall( - void (*db_errcall_fcn)(const char *errpfx, char *msg)); -
The DbEnv::set_errcall method is used to enhance the mechanism for reporting error -messages to the application. In some cases, when an error occurs, Berkeley DB -will call db_errcall_fcn with additional error information. The -function must be defined with two arguments; the first will be the prefix -string (as previously set by Db::set_errpfx or -DbEnv::set_errpfx), the second will be the error message string. -It is up to the db_errcall_fcn method to display the error -message in an appropriate manner. -
Alternatively, you can use the DbEnv::set_error_stream method to display -the additional information via an output stream, or the Db::set_errfile -or DbEnv::set_errfile methods to display the additional information via a C -library FILE *. You should not mix these approaches. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
The DbEnv::set_errcall interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_errfile.html b/bdb/docs/api_cxx/env_set_errfile.html deleted file mode 100644 index e9658cd18ec..00000000000 --- a/bdb/docs/api_cxx/env_set_errfile.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - -
-
-DbEnv::set_errfile- |
-
-
- |
-#include <db_cxx.h> --void DbEnv::set_errfile(FILE *errfile); -
The DbEnv::set_errfile method is used to enhance the mechanism for reporting error -messages to the application by setting a C library FILE * to be used for -displaying additional Berkeley DB error messages. In some cases, when an error -occurs, Berkeley DB will output an additional error message to the specified -file reference. -
Alternatively, you can use the DbEnv::set_error_stream method to display -the additional information via an output stream, or the -DbEnv::set_errcall method to capture the additional error information in -a way that does not use either output streams or C library FILE *'s. You -should not mix these approaches. -
The error message will consist of the prefix string and a colon -(":") (if a prefix string was previously specified using -Db::set_errpfx or DbEnv::set_errpfx), an error string, and -a trailing <newline> character. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
The DbEnv::set_errfile interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_error_stream.html b/bdb/docs/api_cxx/env_set_error_stream.html deleted file mode 100644 index 18dc192cc77..00000000000 --- a/bdb/docs/api_cxx/env_set_error_stream.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - -
-
-DbEnv::set_error_stream- |
-
-
- |
-#include <db_cxx.h> --void DbEnv::set_error_stream(class ostream*); -
When an error occurs in the Berkeley DB library, an exception is thrown or an -errno value is returned by the method. In some cases, -however, the errno value may be insufficient to completely -describe the cause of the error, especially during initial application -debugging. -
The DbEnv::set_error_stream method is used to enhance the mechanism for -reporting error messages to the application by setting the C++ ostream -used for displaying additional Berkeley DB error messages. In some cases, -when an error occurs, Berkeley DB will output an additional error message to -the specified stream. -
The error message will consist of the prefix string and a colon -(":") (if a prefix string was previously specified using -DbEnv::set_errpfx), an error string, and a trailing -<newline> character. -
Alternatively, you can use the DbEnv::set_errfile method to display -the additional information via a C library FILE *, or the -DbEnv::set_errcall method to capture the additional error information in -a way that does not use either output streams or C library FILE *'s. You -should not mix these approaches. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_errpfx.html b/bdb/docs/api_cxx/env_set_errpfx.html deleted file mode 100644 index 62167d96ed4..00000000000 --- a/bdb/docs/api_cxx/env_set_errpfx.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - -
-
-DbEnv::set_errpfx- |
-
-
- |
-#include <db_cxx.h> --void DbEnv::set_errpfx(const char *errpfx); -
Set the prefix string that appears before error messages issued by Berkeley DB. -
The DbEnv::set_errpfx method does not copy the memory referenced by the -errpfx argument, rather, it maintains a reference to it. This -allows applications to modify the error message prefix at any time, -without repeatedly calling DbEnv::set_errpfx, but means that the -memory must be maintained until the handle is closed. -
The DbEnv::set_errpfx interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_feedback.html b/bdb/docs/api_cxx/env_set_feedback.html deleted file mode 100644 index 147a5dc5930..00000000000 --- a/bdb/docs/api_cxx/env_set_feedback.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-DbEnv::set_feedback- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_feedback( - void (*db_feedback_fcn)(DbEnv *, int opcode, int pct)); -
Some operations performed by the Berkeley DB library can take non-trivial -amounts of time. The DbEnv::set_feedback method can be used by -applications to monitor progress within these operations. -
When an operation is likely to take a long time, Berkeley DB will call the -specified callback method. This method must be declared with -three arguments: the first will be a reference to the enclosing -environment, the second a flag value, and the third the percent of the -operation that has been completed, specified as an integer value between -0 and 100. It is up to the callback method to display this -information in an appropriate manner. -
The opcode argument may take on any of the following values: -
The DbEnv::set_feedback interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv::set_feedback method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_flags.html b/bdb/docs/api_cxx/env_set_flags.html deleted file mode 100644 index ad8f4fc1ce2..00000000000 --- a/bdb/docs/api_cxx/env_set_flags.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-DbEnv::set_flags- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_flags(u_int32_t flags, int onoff); -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -If onoff is zero, the specified flags are cleared, otherwise they -are set. -
The number of transactions that are potentially at risk is governed by -how often the log is checkpointed (see db_checkpoint for more -information) and how many log updates can fit on a single log page. -
The DbEnv::set_flags method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's flag values may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_flags", one or more whitespace characters, -and the interface flag argument as a string, for example, "set_flags -DB_TXN_NOSYNC". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lg_bsize.html b/bdb/docs/api_cxx/env_set_lg_bsize.html deleted file mode 100644 index fb9efecef3f..00000000000 --- a/bdb/docs/api_cxx/env_set_lg_bsize.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv::set_lg_bsize- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lg_bsize(u_int32_t lg_bsize); -
Set the size of the in-memory log buffer, in bytes. By default, or if -the value is set to 0, a size of 32K is used. -
Log information is stored in-memory until the storage space fills up -or transaction commit forces the information to be flushed to stable -storage. In the presence of long-running transactions or transactions -producing large amounts of data, larger buffer sizes can increase -throughput. -
The DbEnv::set_lg_bsize interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lg_bsize method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's log buffer size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_bsize", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lg_dir.html b/bdb/docs/api_cxx/env_set_lg_dir.html deleted file mode 100644 index 9a97eb3fe00..00000000000 --- a/bdb/docs/api_cxx/env_set_lg_dir.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-DbEnv::set_lg_dir- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lg_dir(const char *dir); -
The path of a directory to be used as the location of logging files. -Log files created by the Log Manager subsystem will be created in this -directory. -
If no logging directory is specified, log files are created in the -environment home directory. See Berkeley DB File Naming for more information. -
For the greatest degree of recoverability from system or application -failure, database files and log files should be located on separate -physical devices. -
The DbEnv::set_lg_dir interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lg_dir method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's logging directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lg_max.html b/bdb/docs/api_cxx/env_set_lg_max.html deleted file mode 100644 index c0f27d19b20..00000000000 --- a/bdb/docs/api_cxx/env_set_lg_max.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv::set_lg_max- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lg_max(u_int32_t lg_max); -
Set the maximum size of a single file in the log, in bytes. Because -DbLsn file offsets are unsigned 4-byte values, the set value may -not be larger than the maximum unsigned 4-byte value. By default, or if -the value is set to 0, a size of 10MB is used. -
See Log File Limits -for more information. -
The DbEnv::set_lg_max interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lg_max method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's log file size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_max", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
The specified log file size was too large. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lk_conflicts.html b/bdb/docs/api_cxx/env_set_lk_conflicts.html deleted file mode 100644 index 9ef5e8c7802..00000000000 --- a/bdb/docs/api_cxx/env_set_lk_conflicts.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv::set_lk_conflicts- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lk_conflicts(u_int8_t *conflicts, int nmodes); -
Set the locking conflicts matrix. -The conflicts argument -is an nmodes by nmodes array. -A non-0 value for the array element: -
-conflicts[requested_mode][held_mode]
indicates that requested_mode and held_mode conflict. The -not-granted mode must be represented by 0. -
If no conflicts value is specified, the conflicts array -db_rw_conflicts is used; see Standard Lock Modes for a description of that array. -
The DbEnv::set_lk_conflicts interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lk_conflicts method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lk_detect.html b/bdb/docs/api_cxx/env_set_lk_detect.html deleted file mode 100644 index ee17ce2a46c..00000000000 --- a/bdb/docs/api_cxx/env_set_lk_detect.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-DbEnv::set_lk_detect- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lk_detect(u_int32_t detect); -
Set if the deadlock detector is to be run whenever a lock conflict occurs, -and specify which transaction should be aborted in the case of a deadlock. -The specified value must be one of the following list: -
The DbEnv::set_lk_detect interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lk_detect method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's deadlock detector configuration may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_detect", one or more whitespace characters, -and the interface detect argument as a string, for example, -"set_lk_detect DB_LOCK_OLDEST". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lk_max.html b/bdb/docs/api_cxx/env_set_lk_max.html deleted file mode 100644 index 7e614d4ac6f..00000000000 --- a/bdb/docs/api_cxx/env_set_lk_max.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-DbEnv::set_lk_max- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lk_max(u_int32_t max); -
The DbEnv::set_lk_max method interface has been deprecated in favor of -the DbEnv::set_lk_max_locks, DbEnv::set_lk_max_lockers, -and DbEnv::set_lk_max_objects methods. Please update your applications. -
Set each of the maximum number of locks, lockers and lock objects -supported by the Berkeley DB lock subsystem to max. This value is -used by DbEnv::open to estimate how much space to allocate for -various lock-table data structures. For specific information on -configuring the size of the lock subsystem, see -Configuring locking: sizing the -system. -
The DbEnv::set_lk_max interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lk_max method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's maximum number of locks may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max", one or more whitespace characters, -and the number of locks. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lk_max_lockers.html b/bdb/docs/api_cxx/env_set_lk_max_lockers.html deleted file mode 100644 index 9e84c0150fb..00000000000 --- a/bdb/docs/api_cxx/env_set_lk_max_lockers.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv::set_lk_max_lockers- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lk_max_lockers(u_int32_t max); -
Set the maximum number of simultaneous locking entities supported by -the Berkeley DB lock subsystem. This value is used by DbEnv::open to -estimate how much space to allocate for various lock-table data -structures. For specific information on configuring the size of the -lock subsystem, see -Configuring locking: sizing the system. -
The DbEnv::set_lk_max_lockers interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lk_max_lockers method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's maximum number of lockers may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_lockers", one or more whitespace characters, -and the number of lockers. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lk_max_locks.html b/bdb/docs/api_cxx/env_set_lk_max_locks.html deleted file mode 100644 index 4e296e97939..00000000000 --- a/bdb/docs/api_cxx/env_set_lk_max_locks.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - -
-
-DbEnv::set_lk_max_locks- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lk_max_locks(u_int32_t max); -
Set the maximum number of locks supported by the Berkeley DB lock subsystem. -This value is used by DbEnv::open to estimate how much space to -allocate for various lock-table data structures. For specific -information on configuring the size of the lock subsystem, see -Configuring locking: sizing the system. -
The DbEnv::set_lk_max_locks interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lk_max_locks method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's maximum number of locks may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_locks", one or more whitespace characters, -and the number of locks. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_lk_max_objects.html b/bdb/docs/api_cxx/env_set_lk_max_objects.html deleted file mode 100644 index b196cb92593..00000000000 --- a/bdb/docs/api_cxx/env_set_lk_max_objects.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv::set_lk_max_objects- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_lk_max_objects(u_int32_t max); -
Set the maximum number of simultaneously locked objects supported by -the Berkeley DB lock subsystem. This value is used by DbEnv::open to -estimate how much space to allocate for various lock-table data -structures. For specific information on configuring the size of the -lock subsystem, see -Configuring locking: sizing the system. -
The DbEnv::set_lk_max_objects interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_lk_max_objects method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's maximum number of objects may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_objects", one or more whitespace characters, -and the number of objects. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_mp_mmapsize.html b/bdb/docs/api_cxx/env_set_mp_mmapsize.html deleted file mode 100644 index da7b3b5a698..00000000000 --- a/bdb/docs/api_cxx/env_set_mp_mmapsize.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - -
-
-DbEnv::set_mp_mmapsize- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_mp_mmapsize(size_t mp_mmapsize); -
Files that are opened read-only in the pool (and that satisfy a few other -criteria) are, by default, mapped into the process address space instead -of being copied into the local cache. This can result in better-than-usual -performance, as available virtual memory is normally much larger than the -local cache, and page faults are faster than page copying on many systems. -However, in the presence of limited virtual memory it can cause resource -starvation, and in the presence of large databases, it can result in immense -process sizes. -
Set the maximum file size, in bytes, for a file to be mapped into the -process address space. If no value is specified, it defaults to 10MB. -
The DbEnv::set_mp_mmapsize interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_mp_mmapsize method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's maximum mapped file size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_mp_mmapsize", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_mutexlocks.html b/bdb/docs/api_cxx/env_set_mutexlocks.html deleted file mode 100644 index b728927a2b4..00000000000 --- a/bdb/docs/api_cxx/env_set_mutexlocks.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
-DbEnv::set_mutexlocks- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_mutexlocks(int do_lock); -
Toggle mutex locks. Setting do_lock to a zero value causes -Berkeley DB to grant all requested mutual exclusion mutexes without regard -for their availability. -
This functionality should never be used for any other purpose than -debugging. -
The DbEnv::set_mutexlocks interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv::set_mutexlocks method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_pageyield.html b/bdb/docs/api_cxx/env_set_pageyield.html deleted file mode 100644 index 01247edc50b..00000000000 --- a/bdb/docs/api_cxx/env_set_pageyield.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv::set_pageyield- |
-
-
- |
-#include <db_cxx.h> --static int -DbEnv::set_pageyield(int pageyield); -
Yield the processor whenever requesting a page from the cache. Setting -pageyield to a non-zero value causes Berkeley DB to yield the processor -any time a thread requests a page from the cache. -
The DbEnv::set_pageyield interface affects the entire application, not a single -database or database environment. -
While the DbEnv::set_pageyield interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
This functionality should never be used for any other purpose than stress -testing. -
The DbEnv::set_pageyield interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv::set_pageyield method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_paniccall.html b/bdb/docs/api_cxx/env_set_paniccall.html deleted file mode 100644 index 61950ad0417..00000000000 --- a/bdb/docs/api_cxx/env_set_paniccall.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - - -
-
-DbEnv::set_paniccall- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_paniccall(void (*)(DbEnv *, int)); -
Errors can occur in the Berkeley DB library where the only solution is to shut -down the application and run recovery. (For example, if Berkeley DB is unable -to write log records to disk because there is insufficient disk space.) -In these cases, when the C++ error model has been configured so that the -individual Berkeley DB methods return error codes (see DbException for -more information), the value DB_RUNRECOVERY is returned by Berkeley DB -methods. -
In these cases, it is also often simpler to shut down the application when -such errors occur rather than attempting to gracefully return up the stack. -The DbEnv::set_paniccall method is used to specify a method to be called when -DB_RUNRECOVERY is about to be returned from a Berkeley DB method. When -called, the dbenv argument will be a reference to the current -environment, and the errval argument is the error value that would -have been returned to the calling method. -
The DbEnv::set_paniccall interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv::set_paniccall method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_panicstate.html b/bdb/docs/api_cxx/env_set_panicstate.html deleted file mode 100644 index 6655003ccc4..00000000000 --- a/bdb/docs/api_cxx/env_set_panicstate.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-DbEnv::set_panicstate- |
-
-
- |
-#include <db_cxx.h> --static int -DbEnv::set_panicstate(int panic); -
Toggle the Berkeley DB panic state. Setting panic to a non-zero value -causes Berkeley DB to refuse attempts to call Berkeley DB functions with the -DB_RUNRECOVERY error return. -
The DbEnv::set_panicstate interface affects the entire application, not a single -database or database environment. -
While the DbEnv::set_panicstate interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
The DbEnv::set_panicstate method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_rec_init.html b/bdb/docs/api_cxx/env_set_rec_init.html deleted file mode 100644 index 96af5948541..00000000000 --- a/bdb/docs/api_cxx/env_set_rec_init.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - -
-
-DbEnv::set_recovery_init- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_recovery_init(int (*db_recovery_init_fcn)(DbEnv *)); -
Applications installing application-specific recovery methods need -to be called before Berkeley DB performs recovery so they may add their recovery -methods to Berkeley DB's. -
The DbEnv::set_recovery_init method supports this functionality. The -db_recovery_init_fcn method must be declared with one -argument, a reference to the enclosing Berkeley DB environment. This -method will be called after the DbEnv::open has been called, -but before recovery is started. -
If the db_recovery_init_fcn method returns a non-zero value, -no recovery will be performed and DbEnv::open will return the same -value to its caller. -
The DbEnv::set_recovery_init interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_recovery_init method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_region_init.html b/bdb/docs/api_cxx/env_set_region_init.html deleted file mode 100644 index f052adaf69e..00000000000 --- a/bdb/docs/api_cxx/env_set_region_init.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - -
-
-DbEnv::set_region_init- |
-
-
- |
-#include <db_cxx.h> --static int -DbEnv::set_region_init(int region_init); -
Page-fault shared regions into memory when initially creating or joining -a Berkeley DB environment. In some applications, the expense of page-faulting -the shared memory regions can affect performance, e.g., when the -page-fault occurs while holding a lock, other lock requests can convoy -and overall throughput may decrease. Setting region_init to a -non-zero value specifies that shared regions be read or written, as -appropriate, when the region is joined by the application. This forces -the underlying virtual memory and file systems to instantiate both the -necessary memory and the necessary disk space. This can also avoid -out-of-disk space failures later on. -
The DbEnv::set_region_init interface affects the entire application, not a single -database or database environment. -
While the DbEnv::set_region_init interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
The DbEnv::set_region_init method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's initial behavior with respect to shared memory regions may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_region_init", one or more whitespace characters, -and the string "1". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_server.html b/bdb/docs/api_cxx/env_set_server.html deleted file mode 100644 index 208c9cc9c3a..00000000000 --- a/bdb/docs/api_cxx/env_set_server.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - -
-
-DbEnv::set_server- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_server(char *host, - long cl_timeout, long sv_timeout, u_int32_t flags); -
Connects to the DB server on the indicated hostname and sets up a channel -for communication. -
The cl_timeout argument specifies the number of seconds the client -should wait for results to come back from the server. Once the timeout -has expired on any communication with the server, DB_NOSERVER will -be returned. If this value is zero, a default timeout is used. -
The sv_timeout argument specifies the number of seconds the server -should allow a client connection to remain idle before assuming that -client is gone. Once that timeout has been reached, the server releases -all resources associated with that client connection. Subsequent attempts -by that client to communicate with the server result in -DB_NOSERVER_ID indicating that an invalid identifier has been -given to the server. This value can be considered a hint to the server. -The server may alter this value based on its own policies or allowed -values. If this value is zero, a default timeout is used. -
The flags parameter is currently unused, and must be set to 0. -
When the DbEnv::set_server method has been called, any subsequent calls -to Berkeley DB library interfaces may return either DB_NOSERVER or -DB_NOSERVER_ID. -
The DbEnv::set_server method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
dbenv_set_server -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_shm_key.html b/bdb/docs/api_cxx/env_set_shm_key.html deleted file mode 100644 index 643bc1afdb3..00000000000 --- a/bdb/docs/api_cxx/env_set_shm_key.html +++ /dev/null @@ -1,90 +0,0 @@ - - - - -
-
-DbEnv::set_shm_key- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_shm_key(long shm_key); -
Specify a base segment ID for Berkeley DB environment shared memory regions -created in system memory on VxWorks or systems supporting X/Open-style -shared memory interfaces, e.g., UNIX systems supporting -shmget(2) and related System V IPC interfaces. -
This base segment ID will be used when Berkeley DB shared memory regions are -first created. It will be incremented a small integer value each time -a new shared memory region is created, that is, if the base ID is 35, -the first shared memory region created will have a segment ID of 35 and -the next one a segment ID between 36 and 40 or so. A Berkeley DB environment -always creates a master shared memory region, plus an additional shared -memory region for each of the subsystems supported by the environment -(locking, logging, memory pool and transaction), plus an additional -shared memory region for each additional memory pool cache that is -supported. Already existing regions with the same segment IDs will be -removed. See Shared Memory Regions -for more information. -
The intent behind this interface is two-fold: without it, applications -have no way to ensure that two Berkeley DB applications don't attempt to use -the same segment IDs when creating different Berkeley DB environments. In -addition, by using the same segment IDs each time the environment is -created, previously created segments will be removed, and the set of -segments on the system will not grow without bound. -
The DbEnv::set_shm_key interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_shm_key method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's base segment ID may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_shm_key", one or more whitespace characters, -and the ID. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_tas_spins.html b/bdb/docs/api_cxx/env_set_tas_spins.html deleted file mode 100644 index fd21f03d341..00000000000 --- a/bdb/docs/api_cxx/env_set_tas_spins.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - -
-
-DbEnv::set_tas_spins- |
-
-
- |
-#include <db_cxx.h> --static int -DbEnv::set_tas_spins(u_int32_t tas_spins); -
Specify that test-and-set mutexes should spin tas_spins times -without blocking. The value defaults to 1 on uniprocessor systems and -to 50 times the number of processors on multiprocessor systems. -
The DbEnv::set_tas_spins interface affects the entire application, not a single -database or database environment. -
While the DbEnv::set_tas_spins interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
The DbEnv::set_tas_spins method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's test-and-set spin count may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tas_spins", one or more whitespace characters, -and the number of spins. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_tmp_dir.html b/bdb/docs/api_cxx/env_set_tmp_dir.html deleted file mode 100644 index 5993fe8a84a..00000000000 --- a/bdb/docs/api_cxx/env_set_tmp_dir.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-DbEnv::set_tmp_dir- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_tmp_dir(const char *dir); -
The path of a directory to be used as the location of temporary files. -The files created to back in-memory access method databases will be -created relative to this path. These temporary files can be quite large, -depending on the size of the database. -
If no directories are specified, the following alternatives are checked -in the specified order. The first existing directory path is used for -all temporary files. -
Note: environment variables are only checked if one of the -DB_USE_ENVIRON or DB_USE_ENVIRON_ROOT flags were -specified. -
Note: the GetTempPath interface is only checked on Win/32 platforms. -
The DbEnv::set_tmp_dir interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_tmp_dir method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's temporary file directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tmp_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_tx_max.html b/bdb/docs/api_cxx/env_set_tx_max.html deleted file mode 100644 index 9189528948c..00000000000 --- a/bdb/docs/api_cxx/env_set_tx_max.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - -
-
-DbEnv::set_tx_max- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_tx_max(u_int32_t tx_max); -
Set the maximum number of active transactions that are supported by the -environment. This value bounds the size of backing shared memory regions. -Note that child transactions must be counted as active until their -ultimate parent commits or aborts. -
When there are more than the specified number of concurrent transactions, -calls to DbEnv::txn_begin will fail (until some active transactions -complete). If no value is specified, a default value of 20 is used. -
The DbEnv::set_tx_max interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_tx_max method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's maximum number of active transactions may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tx_max", one or more whitespace characters, -and the number of transactions. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_tx_recover.html b/bdb/docs/api_cxx/env_set_tx_recover.html deleted file mode 100644 index 08ceec64d47..00000000000 --- a/bdb/docs/api_cxx/env_set_tx_recover.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DbEnv::set_tx_recover- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_tx_recover(int (*)(DbEnv *dbenv, - Dbt *log_rec, DbLsn *lsn, db_recops op)); -
Set the application's method to be called during transaction abort -and recovery. This method must return 0 on success and either -errno or a value outside of the Berkeley DB error name space on -failure. It takes four arguments: -
The DbEnv::set_tx_recover interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_tx_recover method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
Called after DbEnv::open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_tx_timestamp.html b/bdb/docs/api_cxx/env_set_tx_timestamp.html deleted file mode 100644 index fa793324ca9..00000000000 --- a/bdb/docs/api_cxx/env_set_tx_timestamp.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-DbEnv::set_tx_timestamp- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_tx_timestamp(time_t *timestamp); -
Recover to the time specified by timestamp rather than to the most -current possible date. -The timestamp argument should be the number of seconds since 0 -hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal Time, -i.e., the Epoch. -
Once a database environment has been upgraded to a new version of Berkeley DB -involving a log format change (see Upgrading Berkeley DB installations, it is no longer possible to recover -to a specific time before that upgrade. -
The DbEnv::set_tx_timestamp interface may only be used to configure Berkeley DB before -the DbEnv::open interface is called. -
The DbEnv::set_tx_timestamp method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
It is not possible to recover to the specified time using the -log files currently present in the environment. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_set_verbose.html b/bdb/docs/api_cxx/env_set_verbose.html deleted file mode 100644 index 48b2809645e..00000000000 --- a/bdb/docs/api_cxx/env_set_verbose.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - -
-
-DbEnv::set_verbose- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::set_verbose(u_int32_t which, int onoff); -
The DbEnv::set_verbose method turns additional informational and -debugging messages in the Berkeley DB message output on and off. If -onoff is set to -non-zero, -the additional messages are output. -
The which parameter must be set to one of the following values: -
The DbEnv::set_verbose interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv::set_verbose method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The database environment's verbosity may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_verbose", one or more whitespace characters, -and the interface which argument as a string, for example, -"set_verbose DB_VERB_CHKPOINT". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_strerror.html b/bdb/docs/api_cxx/env_strerror.html deleted file mode 100644 index e1572018be3..00000000000 --- a/bdb/docs/api_cxx/env_strerror.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
-DbEnv::strerror- |
-
-
- |
-#include <db_cxx.h> --static char * -DbEnv::strerror(int error); -
The DbEnv::strerror method returns an error message string corresponding -to the error number error. This interface is a superset of the -ANSI C X3.159-1989 (ANSI C) strerror(3) interface. If the error number -error is greater than or equal to 0, then the string returned by -the system interface strerror(3) is returned. If the error -number is less than 0, an error string appropriate to the corresponding -Berkeley DB library error is returned. See -Error returns to applications -for more information. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/env_version.html b/bdb/docs/api_cxx/env_version.html deleted file mode 100644 index 8d40aa8c5df..00000000000 --- a/bdb/docs/api_cxx/env_version.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-DbEnv::version- |
-
-
- |
-#include <db_cxx.h> --static char * -DbEnv::version(int *major, int *minor, int *patch); -
The DbEnv::version method returns a pointer to a string containing Berkeley DB -version information. If major is non-NULL, the major version -of the Berkeley DB release is stored in the memory it references. If -minor is non-NULL, the minor version of the Berkeley DB release is -stored in the memory it references. If patch is non-NULL, the -patch version of the Berkeley DB release is stored in the memory it references. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/except_class.html b/bdb/docs/api_cxx/except_class.html deleted file mode 100644 index 063bede9530..00000000000 --- a/bdb/docs/api_cxx/except_class.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - -
-
-DbException- |
-
-
- |
-#include <db_cxx.h> --class DbException { - DbException(int err); - DbException(const char *description); - DbException(const char *prefix, int err); - DbException(const char *prefix1, const char *prefix2, int err); -}; -
This manual page describes the DbException class and how it is used -by the various Berkeley DB classes. -
Most methods in the Berkeley DB classes return an int but also throw an -exception. This allows for two different error behaviors. By default, -the Berkeley DB C++ API is configured to throw an exception whenever a serious -error occurs. This generally allows for cleaner logic for transaction -processing, as a try block can surround a single transaction. -Alternatively, Berkeley DB can be configured to not throw exceptions, and -instead have the individual function return an error code, by setting -the constructor flags for the Db and DbEnv objects. -
A DbException object contains an informational string and an errno. -The errno can be obtained by using DbException::get_errno. -The informational string can be obtained by using DbException::what. -
We expect in the future that this class will inherit from the standard -class exception, but certain language implementation bugs currently -prevent this on some platforms. -
Some methods may return non-zero values without issuing an exception. -This occurs in situations that are not normally considered an error, but -when some informational status is returned. For example, Db::get -returns DB_NOTFOUND when a requested key does not appear in the database. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/get_errno.html b/bdb/docs/api_cxx/get_errno.html deleted file mode 100644 index 25c639ac2d6..00000000000 --- a/bdb/docs/api_cxx/get_errno.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - -
-
-DbException::get_errno- |
-
-
- |
-#include <db_cxx.h> --const int -DbException::get_errno(); -
A DbException object contains an informational string and an errno. -The errno can be obtained by using DbException::get_errno. -The informational string can be obtained by using DbException::what. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_class.html b/bdb/docs/api_cxx/lock_class.html deleted file mode 100644 index c0aa324d9f0..00000000000 --- a/bdb/docs/api_cxx/lock_class.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - -
-
-DbLock- |
-
-
- |
-#include <db_cxx.h> --class DbLock { -public: - DbLock(); - DbLock(const DbLock &); - DbLock &operator = (const DbLock &); - ~DbLock(); -}; -
The DbEnv lock methods and the DbLock class are used -to provide general-purpose locking. While designed to work with the -other Db classes, they are also useful for more general locking -purposes. Locks can be shared between processes. -
In most cases, when multiple threads or processes are using locking, the -deadlock detector, db_deadlock should be run. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_detect.html b/bdb/docs/api_cxx/lock_detect.html deleted file mode 100644 index 889d0f52048..00000000000 --- a/bdb/docs/api_cxx/lock_detect.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - -
-
-DbEnv::lock_detect- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::lock_detect(u_int32_t flags, u_int32_t atype, int *aborted); -
The DbEnv::lock_detect method runs one iteration of the deadlock detector. -The deadlock detector traverses the lock table, and for each deadlock -it finds, marks one of the participating transactions for abort. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The atype parameter specifies which transaction to abort in the -case of deadlock. It must be set to one of possible arguments listed for -the DbEnv::set_lk_detect interface. -
If the aborted parameter is non-NULL, the memory location it -references will be set to the number of transactions aborted by the -DbEnv::lock_detect method. -
The DbEnv::lock_detect method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::lock_detect method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::lock_detect method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_get.html b/bdb/docs/api_cxx/lock_get.html deleted file mode 100644 index 4dae9f5dc67..00000000000 --- a/bdb/docs/api_cxx/lock_get.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-DbEnv::lock_get- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::lock_get(u_int32_t locker, u_int32_t flags, - const Dbt *obj, const db_lockmode_t lock_mode, DbLock *lock); -
The DbEnv::lock_get method acquires a lock from the lock table, returning -information about it in -the lock argument. -
The locker argument specified to DbEnv::lock_get is an unsigned -32-bit integer quantity. It represents the entity requesting or releasing -the lock. -
The flags value must be set to 0 or the following value: -
The obj argument is an untyped byte string that specifies the -object to be locked or released. -
The mode argument is an index into the environment's lock conflict -array. See DbEnv::set_lk_conflicts and -Standard Lock Modes -for a description of that array. -
The DbEnv::lock_get method may -return or throw an exception encapsulating -one of the following values: -
Otherwise, the DbEnv::lock_get method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::lock_get method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::lock_get method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::lock_get method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_id.html b/bdb/docs/api_cxx/lock_id.html deleted file mode 100644 index 72ab2a274db..00000000000 --- a/bdb/docs/api_cxx/lock_id.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - -
-
-DbEnv::lock_id- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::lock_id(u_int32_t *idp); -
The DbEnv::lock_id method -copies a locker ID, which is guaranteed to be unique in the specified lock -table, into the memory location referenced by idp. -
The DbEnv::lock_id method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::lock_id method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::lock_id method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_put.html b/bdb/docs/api_cxx/lock_put.html deleted file mode 100644 index 2875e4cfed4..00000000000 --- a/bdb/docs/api_cxx/lock_put.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-DbLock::put- |
-
-
- |
-#include <db_cxx.h> --int -DbLock::put(DbEnv *env); -
The DbLock::put method releases lock from the lock table. -
The DbLock::put method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbLock::put method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbLock::put method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbLock::put method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_stat.html b/bdb/docs/api_cxx/lock_stat.html deleted file mode 100644 index 87bdc9d75a4..00000000000 --- a/bdb/docs/api_cxx/lock_stat.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - -
-
-DbEnv::lock_stat- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -DbEnv::lock_stat(DB_LOCK_STAT **statp, db_malloc_fcn_type db_malloc); -
The DbEnv::lock_stat method -creates a statistical structure and copies a pointer to it into a -user-specified memory location. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The lock region statistics are stored in a structure of type -DB_LOCK_STAT. The following DB_LOCK_STAT fields will be filled in: -
The DbEnv::lock_stat method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::lock_stat method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::lock_stat method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lock_vec.html b/bdb/docs/api_cxx/lock_vec.html deleted file mode 100644 index 46180f2cee8..00000000000 --- a/bdb/docs/api_cxx/lock_vec.html +++ /dev/null @@ -1,127 +0,0 @@ - - - - -
-
-DbEnv::lock_vec- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::lock_vec(u_int32_t locker, u_int32_t flags, - DB_LOCKREQ list[], int nlist, DB_LOCKREQ **elistp); -
The DbEnv::lock_vec method atomically obtains and releases one or more locks -from the lock table. The DbEnv::lock_vec method is intended to support -acquisition or trading of multiple locks under one lock table semaphore, -as is needed for lock coupling or in multigranularity locking for lock -escalation. -
The locker argument specified to DbEnv::lock_vec is an unsigned -32-bit integer quantity. It represents the entity requesting or releasing -the lock. -
The flags value must be set to 0 or the following value: -
The list array provided to DbEnv::lock_vec is typedef'd as -DB_LOCKREQ. A DB_LOCKREQ structure has at least the following fields, -which must be initialized before calling DbEnv::lock_vec: -
The nlist argument specifies the number of elements in the -list array. -
If any of the requested locks cannot be acquired, or any of the locks to -be released cannot be released, the operations before the failing -operation are guaranteed to have completed successfully, and -DbEnv::lock_vec returns a non-zero value. In addition, if elistp -is not NULL, it is set to point to the DB_LOCKREQ entry that was being -processed when the error occurred. -
The DbEnv::lock_vec method may -return or throw an exception encapsulating -one of the following values: -
Otherwise, the DbEnv::lock_vec method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::lock_vec method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::lock_vec method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::lock_vec method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_archive.html b/bdb/docs/api_cxx/log_archive.html deleted file mode 100644 index e5436431a02..00000000000 --- a/bdb/docs/api_cxx/log_archive.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - -
-
-DbEnv::log_archive- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -DbEnv::log_archive(char *(*listp)[], - u_int32_t flags, db_malloc_fcn_type db_malloc); -
The DbEnv::log_archive method -creates a NULL-terminated array of log or database file names and copies -a pointer to them into the user-specified memory location listp. -
By default, DbEnv::log_archive returns the names of all of the log files -that are no longer in use (e.g., no longer involved in active transactions), -and that may safely be archived for catastrophic recovery and then removed -from the system. If there were no file names to return, the memory location -referenced by listp will be set to NULL. -
Arrays of log file names are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_ARCH_DATA and DB_ARCH_LOG flags are mutually -exclusive. -
See the db_archive manual page for more information on database -archival procedures. -
The DbEnv::log_archive method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
In a threaded application (i.e., one where the environment was created -with the DB_THREAD flag specified), calling DbEnv::log_archive with the -DB_ARCH_DATA flag will fail, returning EINVAL. To work around this -problem, re-open the log explicitly without specifying DB_THREAD. This -restriction is expected to be removed in a future version of Berkeley DB. -
The DbEnv::log_archive method may fail and throw an exception or return a non-zero error for the following conditions: -
The log was corrupted. -
The DbEnv::log_archive method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_archive method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_compare.html b/bdb/docs/api_cxx/log_compare.html deleted file mode 100644 index 7d1b7ebb9d6..00000000000 --- a/bdb/docs/api_cxx/log_compare.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - -
-
-DbEnv::log_compare- |
-
-
- |
-#include <db_cxx.h> --static int -DbEnv::log_compare(const DbLsn *lsn0, const DbLsn *lsn1); -
The DbEnv::log_compare method allows the caller to compare two -DbLsn objects, -returning 0 if they are equal, 1 if lsn0 is greater than -lsn1, and -1 if lsn0 is less than lsn1. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_file.html b/bdb/docs/api_cxx/log_file.html deleted file mode 100644 index fa0ed4e5332..00000000000 --- a/bdb/docs/api_cxx/log_file.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - -
-
-DbEnv::log_file- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::log_file(const DbLsn *lsn, char *namep, size_t len); -
The DbEnv::log_file method maps -DbLsn objects -to file names, -copying the name of the file containing the record named by lsn -into the memory location referenced by namep. -
The len argument is the length of the namep buffer in bytes. -If namep is too short to hold the file name, DbEnv::log_file will -return ENOMEM. -(Log file names are normally quite short, on the order of 10 characters.) -
This mapping of -DbLsn objects -to files is needed for database administration. For example, a -transaction manager typically records the earliest -DbLsn -needed for restart, and the database administrator may want to archive -log files to tape when they contain only -DbLsn -entries before the earliest one needed for restart. -
The DbEnv::log_file method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_file method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::log_file method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_file method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_flush.html b/bdb/docs/api_cxx/log_flush.html deleted file mode 100644 index ecb13b9c0c6..00000000000 --- a/bdb/docs/api_cxx/log_flush.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-DbEnv::log_flush- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::log_flush(const DbLsn *lsn); -
The DbEnv::log_flush method guarantees that all log records whose -DbLsn values -are less than or equal to the lsn argument have been -written to disk. If lsn is NULL, all records in the -log are flushed. -
The DbEnv::log_flush method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_flush method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::log_flush method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_flush method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_get.html b/bdb/docs/api_cxx/log_get.html deleted file mode 100644 index 37a8c497bbc..00000000000 --- a/bdb/docs/api_cxx/log_get.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - -
-
-DbEnv::log_get- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::log_get(DbLsn *lsn, Dbt *data, u_int32_t flags); -
The DbEnv::log_get method implements a cursor inside of the log, -retrieving records from the log according to the lsn and -flags arguments. -
The data field of the data structure is set to the record -retrieved and the size field indicates the number of bytes in the record. -See Dbt for a description of other fields in the data -structure. When multiple threads are using the returned log handle -concurrently, one of the DB_DBT_MALLOC, DB_DBT_REALLOC or -DB_DBT_USERMEM flags must be specified for any Dbt used -for data retrieval. -
The flags argument must be set to exactly one of the following values: -
If the log is empty, the DbEnv::log_get method will return DB_NOTFOUND. -
If the log is empty, the DbEnv::log_get method will return DB_NOTFOUND. -
If the log is empty, the DbEnv::log_get method will return DB_NOTFOUND. -
If the pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, DbEnv::log_get will return the first record in the log. -If the last log record has already been returned or the log is empty, the -DbEnv::log_get method will return DB_NOTFOUND. -
If the log was opened with the DB_THREAD flag set, calls to -DbEnv::log_get with the DB_NEXT flag set will return EINVAL. -
If the pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, -DbEnv::log_get will return the last record in the log. -If the first log record has already been returned or the log is empty, the -DbEnv::log_get method will return DB_NOTFOUND. -
If the log was opened with the DB_THREAD flag set, calls to -DbEnv::log_get with the DB_PREV flag set will return EINVAL. -
If the log pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, or if the log was opened with the DB_THREAD flag set, -DbEnv::log_get will return EINVAL. -
Otherwise, the DbEnv::log_get method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_get method may fail and throw an exception or return a non-zero error for the following conditions: -
The DB_FIRST flag was specified and no log files were found. -
The DbEnv::log_get method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_get method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_put.html b/bdb/docs/api_cxx/log_put.html deleted file mode 100644 index ecd84e33c78..00000000000 --- a/bdb/docs/api_cxx/log_put.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-DbEnv::log_put- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::log_put(DbLsn *lsn, const Dbt *data, u_int32_t flags); -
The DbEnv::log_put method appends records to the log. The DbLsn of -the put record is returned in the lsn argument. The flags -argument may be set to one of the following values: -
The caller is responsible for providing any necessary structure to -data. (For example, in a write-ahead logging protocol, the -application must understand what part of data is an operation -code, what part is redo information, and what part is undo information. -In addition, most transaction managers will store in data the -DbLsn of the previous log record for the same transaction, to -support chaining back through the transaction's log records during -undo.) -
The DbEnv::log_put method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_flush method may fail and throw an exception or return a non-zero error for the following conditions: -
The record to be logged is larger than the maximum log record. -
The DbEnv::log_put method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_put method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_register.html b/bdb/docs/api_cxx/log_register.html deleted file mode 100644 index b837a60b352..00000000000 --- a/bdb/docs/api_cxx/log_register.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DbEnv::log_register- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::log_register(Db *dbp, const char *name); -
The DbEnv::log_register method registers a file name with the specified Berkeley DB -environment's log manager. The log manager records all file name mappings -at each checkpoint so that a recovery process can identify the file to -which a record in the log refers. -
The dbp argument should be a reference to the Db object being -registered. The name argument should be a file name appropriate -for opening the file in the environment, during recovery. -
The DbEnv::log_register method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_register method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::log_register method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_register method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_stat.html b/bdb/docs/api_cxx/log_stat.html deleted file mode 100644 index 061685ab497..00000000000 --- a/bdb/docs/api_cxx/log_stat.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - -
-
-DbEnv::log_stat- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -DbEnv::log_stat(DB_LOG_STAT **spp, db_malloc_fcn_type db_malloc); -
The DbEnv::log_stat method -creates a statistical structure and copies a pointer to it into a -user-specified memory location. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The log region statistics are stored in a structure of type DB_LOG_STAT. -The following DB_LOG_STAT fields will be filled in: -
The DbEnv::log_stat method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_stat method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_stat method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/log_unregister.html b/bdb/docs/api_cxx/log_unregister.html deleted file mode 100644 index 364e62259b5..00000000000 --- a/bdb/docs/api_cxx/log_unregister.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-DbEnv::log_unregister- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::log_unregister(int32_t DB *dbp); -
The DbEnv::log_unregister method function unregisters the file represented by -the dbp parameter from the Berkeley DB environment's log manager. -
The DbEnv::log_unregister method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::log_unregister method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::log_unregister method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::log_unregister method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/lsn_class.html b/bdb/docs/api_cxx/lsn_class.html deleted file mode 100644 index db4d5656794..00000000000 --- a/bdb/docs/api_cxx/lsn_class.html +++ /dev/null @@ -1,38 +0,0 @@ - - - - -
-
-DbLsn- |
-
-
- |
-#include <db_cxx.h> --class DbLsn { ... }; -
A DbLsn is a log sequence number that is fully -encapsulated. The class itself has no methods, other than a default -constructor, so there is no way for the user to manipulate its data -directly. -Methods always take a pointer to a DbLsn as an argument. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_fclose.html b/bdb/docs/api_cxx/memp_fclose.html deleted file mode 100644 index 0906388e3ee..00000000000 --- a/bdb/docs/api_cxx/memp_fclose.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - -
-
-DbMpoolFile::close- |
-
-
- |
-#include <db_cxx.h> --int -DbMpoolFile::close(); -
The DbMpoolFile::close method closes the source file indicated by the -DbMpoolFile object. Calling DbMpoolFile::close does not imply -a call to DbMpoolFile::sync, i.e. no pages are written to the source -file as as a result of calling DbMpoolFile::close. -
In addition, if the file argument to DbMpoolFile::open was NULL, -any underlying files created for this DbMpoolFile will be removed. -
Once DbMpoolFile::close has been called, regardless of its return, the -DbMpoolFile handle may not be accessed again. -
The DbMpoolFile::close method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbMpoolFile::close method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbMpoolFile::close method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_fget.html b/bdb/docs/api_cxx/memp_fget.html deleted file mode 100644 index c8067603c77..00000000000 --- a/bdb/docs/api_cxx/memp_fget.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - -
-
-DbMpoolFile::get- |
-
-
- |
-#include <db_cxx.h> --int -DbMpoolFile::get(db_pgno_t *pgnoaddr, u_int32_t flags, void **pagep); -
The DbMpoolFile::get method copies a pointer to the page with the page -number specified by pgnoaddr, from the source file in the -DbMpoolFile, into the memory location referenced by pagep. -If the page does not exist or cannot be retrieved, DbMpoolFile::get will -fail. -
Page numbers begin at 0, i.e., the first page in the file is page number -0, not page number 1. -
The returned page is size_t type aligned. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_MPOOL_CREATE, DB_MPOOL_LAST and -DB_MPOOL_NEW flags are mutually exclusive. -
Created pages have all their bytes set to 0, unless otherwise specified -when the file was opened. -
All pages returned by DbMpoolFile::get will be retained (i.e. -pinned), in the pool until a subsequent call to -DbMpoolFile::put. -
The DbMpoolFile::get method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbMpoolFile::get method may fail and throw an exception or return a non-zero error for the following conditions: -
The DB_MPOOL_NEW flag was set and the source file was not opened for writing. -
More than one of DB_MPOOL_CREATE, DB_MPOOL_LAST and DB_MPOOL_NEW was set. -
The DbMpoolFile::get method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbMpoolFile::get method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_fopen.html b/bdb/docs/api_cxx/memp_fopen.html deleted file mode 100644 index c993ee6f11d..00000000000 --- a/bdb/docs/api_cxx/memp_fopen.html +++ /dev/null @@ -1,160 +0,0 @@ - - - - -
-
-DbMpoolFile::open- |
-
-
- |
-#include <db_cxx.h> --static int -DbMpoolFile::open(DbEnv *env, const char *file, u_int32_t flags, int mode, - size_t pagesize, DB_MPOOL_FINFO *finfop, DbMpoolFile **mpf); -
The DbMpoolFile::open method opens a file in the pool specified by the -DbEnv env, copying the DbMpoolFile pointer -representing it into the memory location referenced by mpf. -
The file argument is the name of the file to be opened. -If file is NULL, a private file is created that cannot be -shared with any other process (although it may be shared with -other threads). -
The flags and mode arguments specify how files will be opened -and/or created if they do not already exist. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by function DbMpoolFile::open -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
The pagesize argument is the size, in bytes, of the unit of transfer -between the application and the pool, although it is not necessarily the -unit of transfer between the pool and the source file. -
Files opened in the pool may be further configured based on the -finfop argument to DbMpoolFile::open (which is a pointer to a -structure of type DB_MPOOL_FINFO). No references to the finfop -structure are maintained by Berkeley DB, so it may be discarded when the -DbMpoolFile::open function returns. In order to ensure compatibility -with future releases of Berkeley DB, all fields of the DB_MPOOL_FINFO structure -that are not explicitly set should be initialized to 0 before the first -time the structure is used. Do this by declaring the structure external -or static, or by calling the C library routine bzero(3) or -memset(3). -
The fields of the DB_MPOOL_FINFO structure used by DbMpoolFile::open are -described below. If finfop is NULL or any of its fields are -set to their default value, defaults appropriate for the system are used. -
The mpool functions must be able to uniquely identify files in order that -multiple processes wanting to share a file will correctly identify it in -the pool. -
On most UNIX/POSIX systems, the fileid field will not need to be -set and the mpool functions will simply use the file's device and inode -numbers for this purpose. On Windows systems, the mpool functions use -the values returned by GetFileInformationByHandle() by default -- these -values are known to be constant between processes and over reboot in the -case of NTFS (where they are the NTFS MFT indexes). -
On other filesystems, (e.g., FAT or NFS) these default values are not -necessarily unique between processes or across system reboots. -Applications wanting to maintain a shared memory buffer pool -between processes or across system reboots, where the pool contains pages -from files stored on such filesystems, must specify a unique file -identifier to the DbMpoolFile::open call and each process opening or -registering the file must provide the same unique identifier. -
This should not be necessary for most applications. Specifically, it is -not necessary if the memory pool is not shared between processes and is -re-instantiated after each system reboot, or the application is using the -Berkeley DB access methods instead of calling the pool functions explicitly, or -the files in the memory pool are stored on filesystems where the default -values as described above are invariant between process and across system -reboots. -
The DbMpoolFile::open method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbMpoolFile::open method may fail and throw an exception or return a non-zero error for the following conditions: -
The file has already been entered into the pool, and the pagesize -value is not the same as when the file was entered into the pool, or the -length of the file is not zero or a multiple of the pagesize. -
The DB_RDONLY flag was specified for an in-memory pool. -
The DbMpoolFile::open method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbMpoolFile::open method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_fput.html b/bdb/docs/api_cxx/memp_fput.html deleted file mode 100644 index f49c809c093..00000000000 --- a/bdb/docs/api_cxx/memp_fput.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-DbMpoolFile::put- |
-
-
- |
-#include <db_cxx.h> --int -DbMpoolFile::put(void *pgaddr, u_int32_t flags); -
The DbMpoolFile::put method indicates that the page referenced by -pgaddr can be evicted from the pool. The pgaddr -argument must be an address previously returned by DbMpoolFile::get. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_MPOOL_CLEAN and DB_MPOOL_DIRTY flags are -mutually exclusive. -
The DbMpoolFile::put method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbMpoolFile::put method may fail and throw an exception or return a non-zero error for the following conditions: -
The pgaddr parameter does not reference a page returned by -DbMpoolFile::get. -
More than one of DB_MPOOL_CLEAN and DB_MPOOL_DIRTY flags was set. -
The DbMpoolFile::put method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbMpoolFile::put method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_fset.html b/bdb/docs/api_cxx/memp_fset.html deleted file mode 100644 index 6e46d45c1f4..00000000000 --- a/bdb/docs/api_cxx/memp_fset.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-DbMpoolFile::set- |
-
-
- |
-#include <db_cxx.h> --int -DbMpoolFile::set(void *pgaddr, u_int32_t flags); -
The DbMpoolFile::set method sets the flags associated with the page referenced -by pgaddr without unpinning it from the pool. The pgaddr -argument must be an address previously returned by DbMpoolFile::get. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The DB_MPOOL_CLEAN and DB_MPOOL_DIRTY flags are -mutually exclusive. -
The DbMpoolFile::set method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbMpoolFile::set method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbMpoolFile::set method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbMpoolFile::set method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_fsync.html b/bdb/docs/api_cxx/memp_fsync.html deleted file mode 100644 index a38366f9e18..00000000000 --- a/bdb/docs/api_cxx/memp_fsync.html +++ /dev/null @@ -1,63 +0,0 @@ - - - - -
-
-DbMpoolFile::sync- |
-
-
- |
-#include <db_cxx.h> --int -DbMpoolFile::sync(); -
The DbMpoolFile::sync method writes all pages associated with the -DbMpoolFile, that were marked as modified using DbMpoolFile::put -or DbMpoolFile::set, back to the source file. If any of the modified -pages are also pinned (i.e., currently referenced by this or -another process) DbMpoolFile::sync will ignore them. -
The DbMpoolFile::sync method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if there were pages which were -modified but which DbMpoolFile::sync was unable to write immediately. -
The DbMpoolFile::sync method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbMpoolFile::sync method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_register.html b/bdb/docs/api_cxx/memp_register.html deleted file mode 100644 index 4c5f0748e98..00000000000 --- a/bdb/docs/api_cxx/memp_register.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - -
-
-DbEnv::memp_register- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef int (*pgin_fcn_type)(DB_ENV *dbenv, - db_pgno_t pgno, void *pgaddr, DBT *pgcookie); - typedef int (*pgout_fcn_type)(DB_ENV *dbenv, - db_pgno_t pgno, void *pgaddr, DBT *pgcookie); -}; -int -DbEnv::memp_register(int ftype, - pgin_fcn_type pgin_fcn, pgout_fcn_type pgout_fcn); -
The DbEnv::memp_register method registers page-in and page-out -functions for files of type ftype in the specified pool. -
If the pgin_fcn function is non-NULL, it is called each time -a page is read into the memory pool from a file of type ftype, or -a page is created for a file of type ftype (see the -DB_MPOOL_CREATE flag for the DbMpoolFile::get method). -
If the pgout_fcn function is non-NULL, it is called each time -a page is written to a file of type ftype. -
Both the pgin_fcn and pgout_fcn functions are called with -a reference to the current environment, the page number, a pointer to the -page being read or written, and any argument pgcookie that was -specified to the DbMpoolFile::open function when the file was opened. -The pgin_fcn and pgout_fcn functions should return 0 on -success, and an applicable non-zero errno value on failure, in -which case the shared memory pool interface routine (and, by extension, -any Berkeley DB library function) calling it will also fail, returning that -errno value. -
The purpose of the DbEnv::memp_register function is to support processing -when pages are entered into, or flushed from, the pool. A file type must -be specified to make it possible for unrelated threads or processes, that -are sharing a pool, to evict each other's pages from the pool. -Applications should call DbEnv::memp_register, during initialization, -for each type of file requiring input or output processing that will be -sharing the underlying pool. (No registry is necessary for the standard -Berkeley DB access method types, as Db::open registers them -separately.) -
If a thread or process does not call DbEnv::memp_register for a file -type, it is impossible for it to evict pages for any file requiring input -or output processing from the pool. For this reason, -DbEnv::memp_register should always be called by each application sharing -a pool for each type of file included in the pool, regardless of whether -or not the application itself uses files of that type. -
There are no standard values for ftype, pgin_fcn, -pgout_fcn and pgcookie, except that the ftype -value for a file must be a non-zero positive number, as negative numbers -are reserved for internal use by the Berkeley DB library. For this reason, -applications sharing a pool must coordinate their values amongst -themselves. -
The DbEnv::memp_register method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::memp_register method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::memp_register method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_stat.html b/bdb/docs/api_cxx/memp_stat.html deleted file mode 100644 index 1c7f16a2a98..00000000000 --- a/bdb/docs/api_cxx/memp_stat.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - -
-
-DbEnv::memp_stat- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -DbEnv::memp_stat(DB_MPOOL_STAT **gsp, - DB_MPOOL_FSTAT *(*fsp)[], db_malloc_fcn_type db_malloc); -
The DbEnv::memp_stat method method creates statistical structures and copies -pointers to them into user-specified memory locations. The statistics -include the number of files participating in the pool, the active pages -in the pool, and information as to how effective the cache has been. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
If gsp is non-NULL, the global statistics for the memory pool -mp are copied into the memory location it references. The -global statistics are stored in a structure of type DB_MPOOL_STAT. -
The following DB_MPOOL_STAT fields will be filled in: -
If fsp is non-NULL, a pointer to a NULL-terminated variable -length array of statistics for individual files, in the memory pool mp, -is copied into the memory location it references. If no individual files -currently exist in the memory pool, fsp will be set to NULL. -
The per-file statistics are stored in structures of type DB_MPOOL_FSTAT. -The following DB_MPOOL_FSTAT fields will be filled in for each file in -the pool, i.e., each element of the array: -
The DbEnv::memp_stat method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::memp_stat method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::memp_stat method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::memp_stat method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_sync.html b/bdb/docs/api_cxx/memp_sync.html deleted file mode 100644 index fe63f1dffc4..00000000000 --- a/bdb/docs/api_cxx/memp_sync.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-DbEnv::memp_sync- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::memp_sync(DbLsn *lsn); -
The DbEnv::memp_sync method ensures that any modified pages in the pool with -log sequence numbers less than the lsn argument are written to -disk. If lsn is NULL all modified pages in the pool are -flushed. -
The primary purpose of the DbEnv::memp_sync function is to enable a -transaction manager to ensure, as part of a checkpoint, that all pages -modified by a certain time have been written to disk. Pages in the pool -that cannot be written back to disk immediately (e.g., that are currently -pinned) are written to disk as soon as it is possible to do so. The -expected behavior of the Berkeley DB or other transaction subsystem is to call -the DbEnv::memp_sync function and then, if the return indicates that some -pages could not be written immediately, to wait briefly and retry again -with the same log sequence number until the DbEnv::memp_sync function -returns that all pages have been written. -
To support the DbEnv::memp_sync functionality, it is necessary that the -pool functions know the location of the log sequence number on the page -for each file type. This location should be specified when the file is -opened using the DbMpoolFile::open function. It is not required that -the log sequence number be aligned on the page in any way. -
The DbEnv::memp_sync method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if there were pages which need to be -written but which DbEnv::memp_sync was unable to write immediately. -In addition, if DbEnv::memp_sync returns success, the value of -lsn will be overwritten with the largest log sequence number -from any page which was written by DbEnv::memp_sync to satisfy this -request. -
The DbEnv::memp_sync method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::memp_sync function was called without logging having been -initialized in the environment. -
The DbEnv::memp_sync method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::memp_sync method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/memp_trickle.html b/bdb/docs/api_cxx/memp_trickle.html deleted file mode 100644 index 185bc5481a4..00000000000 --- a/bdb/docs/api_cxx/memp_trickle.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - -
-
-DbEnv::memp_trickle- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::memp_trickle(int pct, int *nwrotep); -
The DbEnv::memp_trickle method ensures that at least pct percent of -the pages in the shared memory pool are clean by writing dirty pages to -their backing files. -If the nwrotep argument is non-NULL, the number of pages that -were written to reach the correct percentage is returned in the memory -location it references. -
The purpose of the DbEnv::memp_trickle function is to enable a memory -pool manager to ensure that a page is always available for reading in new -information without having to wait for a write. -
The DbEnv::memp_trickle method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::memp_trickle method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::memp_trickle method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::memp_trickle method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/mempfile_class.html b/bdb/docs/api_cxx/mempfile_class.html deleted file mode 100644 index ce10974d14d..00000000000 --- a/bdb/docs/api_cxx/mempfile_class.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
-DbMpoolFile- |
-
-
- |
-#include <db_cxx.h> --class DbMpoolFile { ... }; -
This manual page describes the specific details of the DbMpoolFile -class. -
The DbEnv memory pool methods and the DbMpoolFile class -are the library interface that provide general-purpose, page-oriented -buffer management of one or more files. While designed to work with the -other Db classes, they are also useful for more general purposes. -The memory pools are referred to in this document as simply pools. -
Pools may be shared between processes. Pools are usually filled by pages -from one or more files. Pages in the pool are replaced in LRU -(least-recently-used) order, with each new page replacing the page that -has been unused the longest. Pages retrieved from the pool using -DbMpoolFile::get are pinned in the pool until they are -returned to the control of the buffer pool using the DbMpoolFile::put -method. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/pindex.src b/bdb/docs/api_cxx/pindex.src deleted file mode 100644 index cf4a58836d0..00000000000 --- a/bdb/docs/api_cxx/pindex.src +++ /dev/null @@ -1,287 +0,0 @@ -__APIREL__/api_cxx/db_class.html#2 @Db -__APIREL__/api_cxx/db_class.html#DB_CXX_NO_EXCEPTIONS Db@DB_CXX_NO_EXCEPTIONS -__APIREL__/api_cxx/db_class.html#DB_XA_CREATE Db@DB_XA_CREATE -__APIREL__/api_cxx/db_err.html#2 @DbEnv::err -__APIREL__/api_cxx/db_set_errfile.html#2 @Db::set_errfile -__APIREL__/api_cxx/db_set_malloc.html#2 @Db::set_malloc -__APIREL__/api_cxx/db_set_paniccall.html#2 @Db::set_paniccall -__APIREL__/api_cxx/db_set_realloc.html#2 @Db::set_realloc -__APIREL__/api_cxx/dbc_class.html#2 @Dbc -__APIREL__/api_cxx/dbenv_class.html#2 @DbEnv -__APIREL__/api_cxx/dbenv_class.html#DB_CLIENT DbEnv@DB_CLIENT -__APIREL__/api_cxx/dbenv_class.html#DB_CXX_NO_EXCEPTIONS DbEnv@DB_CXX_NO_EXCEPTIONS -__APIREL__/api_cxx/dbt_class.html#2 @Dbt -__APIREL__/api_cxx/dbt_class.html#3 @key/data pairs -__APIREL__/api_cxx/dbt_class.html#data Dbt@data -__APIREL__/api_cxx/dbt_class.html#DB_DBT_MALLOC Dbt@DB_DBT_MALLOC -__APIREL__/api_cxx/dbt_class.html#DB_DBT_REALLOC Dbt@DB_DBT_REALLOC -__APIREL__/api_cxx/dbt_class.html#DB_DBT_USERMEM Dbt@DB_DBT_USERMEM -__APIREL__/api_cxx/dbt_class.html#DB_DBT_PARTIAL Dbt@DB_DBT_PARTIAL -__APIREL__/api_cxx/dbt_class.html#4 retrieved key/data @permanence -__APIREL__/api_cxx/dbt_class.html#5 retrieved @key/data permanence -__APIREL__/api_cxx/dbt_class.html#6 data @alignment -__APIREL__/api_cxx/dbt_class.html#7 logical @record number format -__APIREL__/api_cxx/env_set_errfile.html#2 @DbEnv::set_errfile -__APIREL__/api_cxx/env_set_error_stream.html#2 @DbEnv::set_error_stream -__APIREL__/api_cxx/env_set_paniccall.html#2 @DbEnv::set_paniccall -__APIREL__/api_cxx/except_class.html#2 @DbException -__APIREL__/api_cxx/get_errno.html#2 @DbException::get_errno -__APIREL__/api_cxx/lock_class.html#2 @DbLock -__APIREL__/api_cxx/lsn_class.html#2 @DbLsn -__APIREL__/api_cxx/mempfile_class.html#2 @DbMpoolFile -__APIREL__/api_cxx/txn_class.html#2 @DbTxn -__APIREL__/api_cxx/what.html#2 @DbException::what -__APIREL__/api_cxx/db_close.html#2 @Db::close -__APIREL__/api_cxx/db_close.html#DB_NOSYNC Db::close@DB_NOSYNC -__APIREL__/api_cxx/db_close.html#3 Db::close @DB_INCOMPLETE -__APIREL__/api_cxx/db_cursor.html#2 @Db::cursor -__APIREL__/api_cxx/db_cursor.html#DB_WRITECURSOR Db::cursor@DB_WRITECURSOR -__APIREL__/api_cxx/db_del.html#2 @Db::del -__APIREL__/api_cxx/db_fd.html#2 @Db::fd -__APIREL__/api_cxx/db_get.html#2 @Db::get -__APIREL__/api_cxx/db_get.html#DB_CONSUME Db::get@DB_CONSUME -__APIREL__/api_cxx/db_get.html#DB_CONSUME_WAIT Db::get@DB_CONSUME_WAIT -__APIREL__/api_cxx/db_get.html#DB_GET_BOTH Db::get@DB_GET_BOTH -__APIREL__/api_cxx/db_get.html#DB_SET_RECNO Db::get@DB_SET_RECNO -__APIREL__/api_cxx/db_get.html#DB_RMW Db::get@DB_RMW -__APIREL__/api_cxx/db_get_byteswapped.html#2 @Db::get_byteswapped -__APIREL__/api_cxx/db_get_type.html#2 @Db::get_type -__APIREL__/api_cxx/db_join.html#2 @Db::join -__APIREL__/api_cxx/db_join.html#DB_JOIN_NOSORT Db::join@DB_JOIN_NOSORT -__APIREL__/api_cxx/db_join.html#DB_JOIN_ITEM Db::join@DB_JOIN_ITEM -__APIREL__/api_cxx/db_join.html#DB_RMW Db::join@DB_RMW -__APIREL__/api_cxx/db_key_range.html#2 @Db::key_range -__APIREL__/api_cxx/db_open.html#2 @Db::open -__APIREL__/api_cxx/db_open.html#DB_CREATE Db::open@DB_CREATE -__APIREL__/api_cxx/db_open.html#DB_EXCL Db::open@DB_EXCL -__APIREL__/api_cxx/db_open.html#DB_NOMMAP Db::open@DB_NOMMAP -__APIREL__/api_cxx/db_open.html#DB_RDONLY Db::open@DB_RDONLY -__APIREL__/api_cxx/db_open.html#DB_THREAD Db::open@DB_THREAD -__APIREL__/api_cxx/db_open.html#DB_TRUNCATE Db::open@DB_TRUNCATE -__APIREL__/api_cxx/db_open.html#DB_OLD_VERSION Db::open@DB_OLD_VERSION -__APIREL__/api_cxx/db_put.html#2 @Db::put -__APIREL__/api_cxx/db_put.html#DB_APPEND Db::put@DB_APPEND -__APIREL__/api_cxx/db_put.html#DB_NODUPDATA Db::put@DB_NODUPDATA -__APIREL__/api_cxx/db_put.html#DB_NOOVERWRITE Db::put@DB_NOOVERWRITE -__APIREL__/api_cxx/db_remove.html#2 @Db::remove -__APIREL__/api_cxx/db_rename.html#2 @Db::rename -__APIREL__/api_cxx/db_set_append_recno.html#2 @Db::set_append_recno -__APIREL__/api_cxx/db_set_bt_compare.html#2 @Db::set_bt_compare -__APIREL__/api_cxx/db_set_bt_minkey.html#2 @Db::set_bt_minkey -__APIREL__/api_cxx/db_set_bt_prefix.html#2 @Db::set_bt_prefix -__APIREL__/api_cxx/db_set_cachesize.html#2 @Db::set_cachesize -__APIREL__/api_cxx/db_set_dup_compare.html#2 @Db::set_dup_compare -__APIREL__/api_cxx/db_set_errcall.html#2 @Db::set_errcall -__APIREL__/api_cxx/db_set_errpfx.html#2 @Db::set_errpfx -__APIREL__/api_cxx/db_set_feedback.html#2 @Db::set_feedback -__APIREL__/api_cxx/db_set_feedback.html#DB_UPGRADE Db::set_feedback@DB_UPGRADE -__APIREL__/api_cxx/db_set_feedback.html#DB_VERIFY Db::set_feedback@DB_VERIFY -__APIREL__/api_cxx/db_set_flags.html#2 @Db::set_flags -__APIREL__/api_cxx/db_set_flags.html#DB_DUP Db::set_flags@DB_DUP -__APIREL__/api_cxx/db_set_flags.html#DB_DUPSORT Db::set_flags@DB_DUPSORT -__APIREL__/api_cxx/db_set_flags.html#DB_RECNUM Db::set_flags@DB_RECNUM -__APIREL__/api_cxx/db_set_flags.html#DB_REVSPLITOFF Db::set_flags@DB_REVSPLITOFF -__APIREL__/api_cxx/db_set_flags.html#DB_DUP Db::set_flags@DB_DUP -__APIREL__/api_cxx/db_set_flags.html#DB_DUPSORT Db::set_flags@DB_DUPSORT -__APIREL__/api_cxx/db_set_flags.html#DB_RENUMBER Db::set_flags@DB_RENUMBER -__APIREL__/api_cxx/db_set_flags.html#DB_SNAPSHOT Db::set_flags@DB_SNAPSHOT -__APIREL__/api_cxx/db_set_h_ffactor.html#2 @Db::set_h_ffactor -__APIREL__/api_cxx/db_set_h_hash.html#2 @Db::set_h_hash -__APIREL__/api_cxx/db_set_h_nelem.html#2 @Db::set_h_nelem -__APIREL__/api_cxx/db_set_lorder.html#2 @Db::set_lorder -__APIREL__/api_cxx/db_set_pagesize.html#2 @Db::set_pagesize -__APIREL__/api_cxx/db_set_q_extentsize.html#2 @Db::set_q_extentsize -__APIREL__/api_cxx/db_set_re_delim.html#2 @Db::set_re_delim -__APIREL__/api_cxx/db_set_re_len.html#2 @Db::set_re_len -__APIREL__/api_cxx/db_set_re_pad.html#2 @Db::set_re_pad -__APIREL__/api_cxx/db_set_re_source.html#2 @Db::set_re_source -__APIREL__/api_cxx/db_stat.html#2 @Db::stat -__APIREL__/api_cxx/db_stat.html#DB_CACHED_COUNTS Db::stat@DB_CACHED_COUNTS -__APIREL__/api_cxx/db_stat.html#DB_RECORDCOUNT Db::stat@DB_RECORDCOUNT -__APIREL__/api_cxx/db_sync.html#2 @Db::sync -__APIREL__/api_cxx/db_upgrade.html#2 @Db::upgrade -__APIREL__/api_cxx/db_upgrade.html#DB_DUPSORT Db::upgrade@DB_DUPSORT -__APIREL__/api_cxx/db_upgrade.html#DB_OLD_VERSION Db::upgrade@DB_OLD_VERSION -__APIREL__/api_cxx/db_verify.html#2 @Db::verify -__APIREL__/api_cxx/db_verify.html#DB_SALVAGE Db::verify@DB_SALVAGE -__APIREL__/api_cxx/db_verify.html#DB_AGGRESSIVE Db::verify@DB_AGGRESSIVE -__APIREL__/api_cxx/db_verify.html#DB_NOORDERCHK Db::verify@DB_NOORDERCHK -__APIREL__/api_cxx/db_verify.html#DB_ORDERCHKONLY Db::verify@DB_ORDERCHKONLY -__APIREL__/api_cxx/dbc_close.html#2 @Dbc::close -__APIREL__/api_cxx/dbc_count.html#2 @Dbc::count -__APIREL__/api_cxx/dbc_del.html#2 @Dbc::del -__APIREL__/api_cxx/dbc_dup.html#2 @Dbc::dup -__APIREL__/api_cxx/dbc_dup.html#DB_POSITION Dbc::dup@DB_POSITION -__APIREL__/api_cxx/dbc_get.html#2 @Dbc::get -__APIREL__/api_cxx/dbc_get.html#DB_CURRENT Dbc::get@DB_CURRENT -__APIREL__/api_cxx/dbc_get.html#DB_FIRST Dbc::get@DB_FIRST -__APIREL__/api_cxx/dbc_get.html#DB_LAST Dbc::get@DB_LAST -__APIREL__/api_cxx/dbc_get.html#DB_GET_BOTH Dbc::get@DB_GET_BOTH -__APIREL__/api_cxx/dbc_get.html#DB_GET_RECNO Dbc::get@DB_GET_RECNO -__APIREL__/api_cxx/dbc_get.html#DB_JOIN_ITEM Dbc::get@DB_JOIN_ITEM -__APIREL__/api_cxx/dbc_get.html#DB_NEXT Dbc::get@DB_NEXT -__APIREL__/api_cxx/dbc_get.html#DB_PREV Dbc::get@DB_PREV -__APIREL__/api_cxx/dbc_get.html#DB_NEXT_DUP Dbc::get@DB_NEXT_DUP -__APIREL__/api_cxx/dbc_get.html#DB_NEXT_NODUP Dbc::get@DB_NEXT_NODUP -__APIREL__/api_cxx/dbc_get.html#DB_PREV_NODUP Dbc::get@DB_PREV_NODUP -__APIREL__/api_cxx/dbc_get.html#DB_SET Dbc::get@DB_SET -__APIREL__/api_cxx/dbc_get.html#DB_SET_RANGE Dbc::get@DB_SET_RANGE -__APIREL__/api_cxx/dbc_get.html#DB_SET_RECNO Dbc::get@DB_SET_RECNO -__APIREL__/api_cxx/dbc_get.html#DB_RMW Dbc::get@DB_RMW -__APIREL__/api_cxx/dbc_put.html#2 @Dbc::put -__APIREL__/api_cxx/dbc_put.html#DB_AFTER Dbc::put@DB_AFTER -__APIREL__/api_cxx/dbc_put.html#DB_BEFORE Dbc::put@DB_BEFORE -__APIREL__/api_cxx/dbc_put.html#DB_CURRENT Dbc::put@DB_CURRENT -__APIREL__/api_cxx/dbc_put.html#DB_KEYFIRST Dbc::put@DB_KEYFIRST -__APIREL__/api_cxx/dbc_put.html#DB_KEYLAST Dbc::put@DB_KEYLAST -__APIREL__/api_cxx/dbc_put.html#DB_NODUPDATA Dbc::put@DB_NODUPDATA -__APIREL__/api_cxx/env_close.html#2 @DbEnv::close -__APIREL__/api_cxx/env_open.html#2 @DbEnv::open -__APIREL__/api_cxx/env_open.html#DB_JOINENV DbEnv::open@DB_JOINENV -__APIREL__/api_cxx/env_open.html#DB_INIT_CDB DbEnv::open@DB_INIT_CDB -__APIREL__/api_cxx/env_open.html#DB_INIT_LOCK DbEnv::open@DB_INIT_LOCK -__APIREL__/api_cxx/env_open.html#DB_INIT_LOG DbEnv::open@DB_INIT_LOG -__APIREL__/api_cxx/env_open.html#DB_INIT_MPOOL DbEnv::open@DB_INIT_MPOOL -__APIREL__/api_cxx/env_open.html#DB_INIT_TXN DbEnv::open@DB_INIT_TXN -__APIREL__/api_cxx/env_open.html#DB_RECOVER DbEnv::open@DB_RECOVER -__APIREL__/api_cxx/env_open.html#DB_RECOVER_FATAL DbEnv::open@DB_RECOVER_FATAL -__APIREL__/api_cxx/env_open.html#DB_USE_ENVIRON DbEnv::open@DB_USE_ENVIRON -__APIREL__/api_cxx/env_open.html#DB_USE_ENVIRON_ROOT DbEnv::open@DB_USE_ENVIRON_ROOT -__APIREL__/api_cxx/env_open.html#DB_CREATE DbEnv::open@DB_CREATE -__APIREL__/api_cxx/env_open.html#DB_LOCKDOWN DbEnv::open@DB_LOCKDOWN -__APIREL__/api_cxx/env_open.html#DB_PRIVATE DbEnv::open@DB_PRIVATE -__APIREL__/api_cxx/env_open.html#DB_SYSTEM_MEM DbEnv::open@DB_SYSTEM_MEM -__APIREL__/api_cxx/env_open.html#DB_THREAD DbEnv::open@DB_THREAD -__APIREL__/api_cxx/env_remove.html#2 @DbEnv::remove -__APIREL__/api_cxx/env_remove.html#DB_FORCE DbEnv::remove@DB_FORCE -__APIREL__/api_cxx/env_remove.html#DB_USE_ENVIRON DbEnv::remove@DB_USE_ENVIRON -__APIREL__/api_cxx/env_remove.html#DB_USE_ENVIRON_ROOT DbEnv::remove@DB_USE_ENVIRON_ROOT -__APIREL__/api_cxx/env_set_cachesize.html#2 @DbEnv::set_cachesize -__APIREL__/api_cxx/env_set_data_dir.html#2 @DbEnv::set_data_dir -__APIREL__/api_cxx/env_set_errcall.html#2 @DbEnv::set_errcall -__APIREL__/api_cxx/env_set_errpfx.html#2 @DbEnv::set_errpfx -__APIREL__/api_cxx/env_set_feedback.html#2 @DbEnv::set_feedback -__APIREL__/api_cxx/env_set_feedback.html#DB_RECOVER DbEnv::set_feedback@DB_RECOVER -__APIREL__/api_cxx/env_set_flags.html#2 @DbEnv::set_flags -__APIREL__/api_cxx/env_set_flags.html#DB_CDB_ALLDB DbEnv::set_flags@DB_CDB_ALLDB -__APIREL__/api_cxx/env_set_flags.html#DB_NOMMAP DbEnv::set_flags@DB_NOMMAP -__APIREL__/api_cxx/env_set_flags.html#DB_TXN_NOSYNC DbEnv::set_flags@DB_TXN_NOSYNC -__APIREL__/api_cxx/env_set_lg_bsize.html#2 @DbEnv::set_lg_bsize -__APIREL__/api_cxx/env_set_lg_dir.html#2 @DbEnv::set_lg_dir -__APIREL__/api_cxx/env_set_lg_max.html#2 @DbEnv::set_lg_max -__APIREL__/api_cxx/env_set_lk_conflicts.html#2 @DbEnv::set_lk_conflicts -__APIREL__/api_cxx/env_set_lk_detect.html#2 @DbEnv::set_lk_detect -__APIREL__/api_cxx/env_set_lk_detect.html#DB_LOCK_DEFAULT DbEnv::set_lk_detect@DB_LOCK_DEFAULT -__APIREL__/api_cxx/env_set_lk_detect.html#DB_LOCK_OLDEST DbEnv::set_lk_detect@DB_LOCK_OLDEST -__APIREL__/api_cxx/env_set_lk_detect.html#DB_LOCK_RANDOM DbEnv::set_lk_detect@DB_LOCK_RANDOM -__APIREL__/api_cxx/env_set_lk_detect.html#DB_LOCK_YOUNGEST DbEnv::set_lk_detect@DB_LOCK_YOUNGEST -__APIREL__/api_cxx/env_set_lk_max.html#2 @DbEnv::set_lk_max -__APIREL__/api_cxx/env_set_lk_max_locks.html#2 @DbEnv::set_lk_max_locks -__APIREL__/api_cxx/env_set_lk_max_lockers.html#2 @DbEnv::set_lk_max_lockers -__APIREL__/api_cxx/env_set_lk_max_objects.html#2 @DbEnv::set_lk_max_objects -__APIREL__/api_cxx/env_set_mp_mmapsize.html#2 @DbEnv::set_mp_mmapsize -__APIREL__/api_cxx/env_set_mutexlocks.html#2 @DbEnv::set_mutexlocks -__APIREL__/api_cxx/env_set_pageyield.html#2 @DbEnv::set_pageyield -__APIREL__/api_cxx/env_set_panicstate.html#2 @DbEnv::set_panicstate -__APIREL__/api_cxx/env_set_rec_init.html#2 @DbEnv::set_recovery_init -__APIREL__/api_cxx/env_set_region_init.html#2 @DbEnv::set_region_init -__APIREL__/api_cxx/env_set_server.html#2 @DbEnv::set_server -__APIREL__/api_cxx/env_set_server.html#DB_NOSERVER DbEnv::set_server@DB_NOSERVER -__APIREL__/api_cxx/env_set_server.html#DB_NOSERVER_ID DbEnv::set_server@DB_NOSERVER_ID -__APIREL__/api_cxx/env_set_shm_key.html#2 @DbEnv::set_shm_key -__APIREL__/api_cxx/env_set_tas_spins.html#2 @DbEnv::set_tas_spins -__APIREL__/api_cxx/env_set_tmp_dir.html#2 @DbEnv::set_tmp_dir -__APIREL__/api_cxx/env_set_tx_max.html#2 @DbEnv::set_tx_max -__APIREL__/api_cxx/env_set_tx_recover.html#2 @DbEnv::set_tx_recover -__APIREL__/api_cxx/env_set_tx_recover.html#DB_TXN_BACKWARD_ROLL DbEnv::set_tx_recover@DB_TXN_BACKWARD_ROLL -__APIREL__/api_cxx/env_set_tx_recover.html#DB_TXN_FORWARD_ROLL DbEnv::set_tx_recover@DB_TXN_FORWARD_ROLL -__APIREL__/api_cxx/env_set_tx_recover.html#DB_TXN_ABORT DbEnv::set_tx_recover@DB_TXN_ABORT -__APIREL__/api_cxx/env_set_tx_timestamp.html#2 @DbEnv::set_tx_timestamp -__APIREL__/api_cxx/env_set_verbose.html#2 @DbEnv::set_verbose -__APIREL__/api_cxx/env_set_verbose.html#DB_VERB_CHKPOINT DbEnv::set_verbose@DB_VERB_CHKPOINT -__APIREL__/api_cxx/env_set_verbose.html#DB_VERB_DEADLOCK DbEnv::set_verbose@DB_VERB_DEADLOCK -__APIREL__/api_cxx/env_set_verbose.html#DB_VERB_RECOVERY DbEnv::set_verbose@DB_VERB_RECOVERY -__APIREL__/api_cxx/env_set_verbose.html#DB_VERB_WAITSFOR DbEnv::set_verbose@DB_VERB_WAITSFOR -__APIREL__/api_cxx/env_strerror.html#2 @DbEnv::strerror -__APIREL__/api_cxx/env_version.html#2 @DbEnv::version -__APIREL__/api_cxx/lock_detect.html#2 @DbEnv::lock_detect -__APIREL__/api_cxx/lock_detect.html#DB_LOCK_CONFLICT DbEnv::lock_detect@DB_LOCK_CONFLICT -__APIREL__/api_cxx/lock_get.html#2 @DbEnv::lock_get -__APIREL__/api_cxx/lock_get.html#DB_LOCK_NOWAIT DbEnv::lock_get@DB_LOCK_NOWAIT -__APIREL__/api_cxx/lock_get.html#DB_LOCK_NOTGRANTED DbEnv::lock_get@DB_LOCK_NOTGRANTED -__APIREL__/api_cxx/lock_id.html#2 @DbEnv::lock_id -__APIREL__/api_cxx/lock_put.html#2 @DbLock::put -__APIREL__/api_cxx/lock_stat.html#2 @DbEnv::lock_stat -__APIREL__/api_cxx/lock_vec.html#2 @DbEnv::lock_vec -__APIREL__/api_cxx/lock_vec.html#DB_LOCK_NOWAIT DbEnv::lock_vec@DB_LOCK_NOWAIT -__APIREL__/api_cxx/lock_vec.html#op DbEnv::lock_vec@op -__APIREL__/api_cxx/lock_vec.html#DB_LOCK_GET DbEnv::lock_vec@DB_LOCK_GET -__APIREL__/api_cxx/lock_vec.html#DB_LOCK_PUT DbEnv::lock_vec@DB_LOCK_PUT -__APIREL__/api_cxx/lock_vec.html#DB_LOCK_PUT_ALL DbEnv::lock_vec@DB_LOCK_PUT_ALL -__APIREL__/api_cxx/lock_vec.html#DB_LOCK_PUT_OBJ DbEnv::lock_vec@DB_LOCK_PUT_OBJ -__APIREL__/api_cxx/lock_vec.html#obj DbEnv::lock_vec@obj -__APIREL__/api_cxx/lock_vec.html#mode DbEnv::lock_vec@mode -__APIREL__/api_cxx/lock_vec.html#lock DbEnv::lock_vec@lock -__APIREL__/api_cxx/lock_vec.html#DB_LOCK_NOTGRANTED DbEnv::lock_vec@DB_LOCK_NOTGRANTED -__APIREL__/api_cxx/log_archive.html#2 @DbEnv::log_archive -__APIREL__/api_cxx/log_archive.html#DB_ARCH_ABS DbEnv::log_archive@DB_ARCH_ABS -__APIREL__/api_cxx/log_archive.html#DB_ARCH_DATA DbEnv::log_archive@DB_ARCH_DATA -__APIREL__/api_cxx/log_archive.html#DB_ARCH_LOG DbEnv::log_archive@DB_ARCH_LOG -__APIREL__/api_cxx/log_compare.html#2 @DbEnv::log_compare -__APIREL__/api_cxx/log_file.html#2 @DbEnv::log_file -__APIREL__/api_cxx/log_flush.html#2 @DbEnv::log_flush -__APIREL__/api_cxx/log_get.html#2 @DbEnv::log_get -__APIREL__/api_cxx/log_get.html#DB_CHECKPOINT DbEnv::log_get@DB_CHECKPOINT -__APIREL__/api_cxx/log_get.html#DB_FIRST DbEnv::log_get@DB_FIRST -__APIREL__/api_cxx/log_get.html#DB_LAST DbEnv::log_get@DB_LAST -__APIREL__/api_cxx/log_get.html#DB_NEXT DbEnv::log_get@DB_NEXT -__APIREL__/api_cxx/log_get.html#DB_PREV DbEnv::log_get@DB_PREV -__APIREL__/api_cxx/log_get.html#DB_CURRENT DbEnv::log_get@DB_CURRENT -__APIREL__/api_cxx/log_get.html#DB_SET DbEnv::log_get@DB_SET -__APIREL__/api_cxx/log_put.html#2 @DbEnv::log_put -__APIREL__/api_cxx/log_put.html#DB_CHECKPOINT DbEnv::log_put@DB_CHECKPOINT -__APIREL__/api_cxx/log_put.html#DB_CURLSN DbEnv::log_put@DB_CURLSN -__APIREL__/api_cxx/log_put.html#DB_FLUSH DbEnv::log_put@DB_FLUSH -__APIREL__/api_cxx/log_register.html#2 @DbEnv::log_register -__APIREL__/api_cxx/log_stat.html#2 @DbEnv::log_stat -__APIREL__/api_cxx/log_unregister.html#2 @DbEnv::log_unregister -__APIREL__/api_cxx/memp_fclose.html#2 @DbMpoolFile::close -__APIREL__/api_cxx/memp_fget.html#2 @DbMpoolFile::get -__APIREL__/api_cxx/memp_fget.html#DB_MPOOL_CREATE DbMpoolFile::get@DB_MPOOL_CREATE -__APIREL__/api_cxx/memp_fget.html#DB_MPOOL_LAST DbMpoolFile::get@DB_MPOOL_LAST -__APIREL__/api_cxx/memp_fget.html#DB_MPOOL_NEW DbMpoolFile::get@DB_MPOOL_NEW -__APIREL__/api_cxx/memp_fopen.html#2 @DbMpoolFile::open -__APIREL__/api_cxx/memp_fopen.html#DB_CREATE DbMpoolFile::open@DB_CREATE -__APIREL__/api_cxx/memp_fopen.html#DB_NOMMAP DbMpoolFile::open@DB_NOMMAP -__APIREL__/api_cxx/memp_fopen.html#DB_RDONLY DbMpoolFile::open@DB_RDONLY -__APIREL__/api_cxx/memp_fopen.html#ftype DbMpoolFile::open@ftype -__APIREL__/api_cxx/memp_fopen.html#pgcookie DbMpoolFile::open@pgcookie -__APIREL__/api_cxx/memp_fopen.html#fileid DbMpoolFile::open@fileid -__APIREL__/api_cxx/memp_fopen.html#lsn_offset DbMpoolFile::open@lsn_offset -__APIREL__/api_cxx/memp_fopen.html#clear_len DbMpoolFile::open@clear_len -__APIREL__/api_cxx/memp_fput.html#2 @DbMpoolFile::put -__APIREL__/api_cxx/memp_fput.html#DB_MPOOL_CLEAN DbMpoolFile::put@DB_MPOOL_CLEAN -__APIREL__/api_cxx/memp_fput.html#DB_MPOOL_DIRTY DbMpoolFile::put@DB_MPOOL_DIRTY -__APIREL__/api_cxx/memp_fput.html#DB_MPOOL_DISCARD DbMpoolFile::put@DB_MPOOL_DISCARD -__APIREL__/api_cxx/memp_fset.html#2 @DbMpoolFile::set -__APIREL__/api_cxx/memp_fset.html#DB_MPOOL_CLEAN DbMpoolFile::set@DB_MPOOL_CLEAN -__APIREL__/api_cxx/memp_fset.html#DB_MPOOL_DIRTY DbMpoolFile::set@DB_MPOOL_DIRTY -__APIREL__/api_cxx/memp_fset.html#DB_MPOOL_DISCARD DbMpoolFile::set@DB_MPOOL_DISCARD -__APIREL__/api_cxx/memp_fsync.html#2 @DbMpoolFile::sync -__APIREL__/api_cxx/memp_register.html#2 @DbEnv::memp_register -__APIREL__/api_cxx/memp_stat.html#2 @DbEnv::memp_stat -__APIREL__/api_cxx/memp_sync.html#2 @DbEnv::memp_sync -__APIREL__/api_cxx/memp_trickle.html#2 @DbEnv::memp_trickle -__APIREL__/api_cxx/txn_abort.html#2 @DbTxn::abort -__APIREL__/api_cxx/txn_begin.html#2 @DbEnv::txn_begin -__APIREL__/api_cxx/txn_begin.html#DB_TXN_NOSYNC DbEnv::txn_begin@DB_TXN_NOSYNC -__APIREL__/api_cxx/txn_begin.html#DB_TXN_NOWAIT DbEnv::txn_begin@DB_TXN_NOWAIT -__APIREL__/api_cxx/txn_begin.html#DB_TXN_SYNC DbEnv::txn_begin@DB_TXN_SYNC -__APIREL__/api_cxx/txn_checkpoint.html#2 @DbEnv::txn_checkpoint -__APIREL__/api_cxx/txn_checkpoint.html#DB_FORCE DbEnv::txn_checkpoint@DB_FORCE -__APIREL__/api_cxx/txn_commit.html#2 @DbTxn::commit -__APIREL__/api_cxx/txn_commit.html#DB_TXN_NOSYNC DbTxn::commit@DB_TXN_NOSYNC -__APIREL__/api_cxx/txn_commit.html#DB_TXN_SYNC DbTxn::commit@DB_TXN_SYNC -__APIREL__/api_cxx/txn_id.html#2 @DbTxn::id -__APIREL__/api_cxx/txn_prepare.html#2 @DbTxn::prepare -__APIREL__/api_cxx/txn_stat.html#2 @DbEnv::txn_stat diff --git a/bdb/docs/api_cxx/txn_abort.html b/bdb/docs/api_cxx/txn_abort.html deleted file mode 100644 index f9c863b3e87..00000000000 --- a/bdb/docs/api_cxx/txn_abort.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-DbTxn::abort- |
-
-
- |
-#include <db_cxx.h> --int -DbTxn::abort(); -
The DbTxn::abort method causes an abnormal termination of the -transaction. The log is played backwards and any necessary recovery -operations are initiated through the recover function specified -to DbEnv::open. After the log processing is completed, all locks -held by the transaction are released. As is the case for -DbTxn::commit, applications that require strict two-phase locking -should not explicitly release any locks. -
In the case of nested transactions, aborting a parent transaction causes -all children (unresolved or not) of the parent transaction to be aborted. -
Once the DbTxn::abort method returns, the DbTxn handle may not -be accessed again. -
The DbTxn::abort method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbTxn::abort method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbTxn::abort method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_begin.html b/bdb/docs/api_cxx/txn_begin.html deleted file mode 100644 index 4cacec56088..00000000000 --- a/bdb/docs/api_cxx/txn_begin.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - -
-
-DbEnv::txn_begin- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::txn_begin(DbTxn *parent, DbTxn **tid, u_int32_t flags); -
The DbEnv::txn_begin method creates a new transaction in the environment -and copies a pointer to a DbTxn that uniquely identifies it into -the memory referenced by tid. -
If the parent argument is non-NULL, the new transaction will -be a nested transaction, with the transaction indicated by -parent as its parent. Transactions may be -nested to any level. -
The flags parameter must be set to 0 or one of the following -values: -
This behavior may be set for an entire Berkeley DB environment as part of the -DbEnv::set_flags interface. -
This behavior is the default for Berkeley DB environments unless the -DB_TXN_NOSYNC flag was specified to the DbEnv::set_flags -interface. -
Note: An transaction may not span threads, -i.e., each transaction must begin and end in the same thread, and each -transaction may only be used by a single thread. -
Note: cursors may not span transactions, i.e., each cursor must be opened -and closed within a single transaction. -
Note: a parent transaction may not issue any Berkeley DB operations, except for -DbEnv::txn_begin, DbTxn::abort and DbTxn::commit, while it has -active child transactions (child transactions that have not yet been -committed or aborted). -
The DbEnv::txn_begin method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::txn_begin method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::txn_begin method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::txn_begin method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_checkpoint.html b/bdb/docs/api_cxx/txn_checkpoint.html deleted file mode 100644 index 3bac70bccbc..00000000000 --- a/bdb/docs/api_cxx/txn_checkpoint.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-DbEnv::txn_checkpoint- |
-
-
- |
-#include <db_cxx.h> --int -DbEnv::txn_checkpoint(u_int32_t kbyte, u_int32_t min, u_int32_t flags) const; -
The DbEnv::txn_checkpoint method flushes the underlying memory pool, -writes a checkpoint record to the log and then flushes the log. -
If either kbyte or min is non-zero, the checkpoint is only -done if there has been activity since the last checkpoint and either -more than min minutes have passed since the last checkpoint, -or if more than kbyte kilobytes of log data have been written since -the last checkpoint. -
The flags parameter must be set to 0 or one of the following -values: -
The DbEnv::txn_checkpoint method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, 0 on success, and returns DB_INCOMPLETE if there were pages that needed to be -written to complete the checkpoint but that DbEnv::memp_sync was unable -to write immediately. -
The DbEnv::txn_checkpoint method may fail and throw an exception or return a non-zero error for the following conditions: -
The DbEnv::txn_checkpoint method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::txn_checkpoint method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_class.html b/bdb/docs/api_cxx/txn_class.html deleted file mode 100644 index 7a335f92a1a..00000000000 --- a/bdb/docs/api_cxx/txn_class.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-DbTxn- |
-
-
- |
-#include <db_cxx.h> --class DbTxn { ... }; -
This manual page describes the specific details of the DbTxn class. -
The DbEnv transaction methods and the DbTxn class provide -transaction semantics. Full transaction support is provided by a -collection of modules that provide interfaces to the services required -for transaction processing. These services are recovery, concurrency -control and the management of shared data. -
Transaction semantics can be applied to the access methods described in -Db through method call parameters. -
The model intended for transactional use (and the one that is used by -the access methods) is write-ahead logging to record both before- and -after-images. Locking follows a two-phase protocol, with all locks being -released at transaction commit. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_commit.html b/bdb/docs/api_cxx/txn_commit.html deleted file mode 100644 index 16e20c2535c..00000000000 --- a/bdb/docs/api_cxx/txn_commit.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-DbTxn::commit- |
-
-
- |
-#include <db_cxx.h> --int -DbTxn::commit(u_int32_t flags); -
The DbTxn::commit method ends the transaction. In the case of nested -transactions, if the transaction is a parent transaction, committing -the parent transaction causes all unresolved children of the parent to -be committed. -
In the case of nested transactions, if the transaction is a child -transaction, its locks are not released, but are acquired by its parent. -While the commit of the child transaction will succeed, the actual -resolution of the child transaction is postponed until the parent -transaction is committed or aborted, i.e., if its parent transaction -commits, it will be committed, and if its parent transaction aborts, it -will be aborted. -
The flags parameter must be set to 0 or one of the following -values: -
This behavior may be set for an entire Berkeley DB environment as part of the -DbEnv::set_flags interface. -
This behavior is the default for Berkeley DB environments unless the -DB_TXN_NOSYNC flag was specified to the DbEnv::set_flags -or DbEnv::txn_begin interfaces. -
Once the DbTxn::commit method returns, the DbTxn handle may not -be accessed again. If DbTxn::commit encounters an error, the -transaction and all child transactions of the transaction are aborted. -
The DbTxn::commit method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbTxn::commit method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbTxn::commit method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_id.html b/bdb/docs/api_cxx/txn_id.html deleted file mode 100644 index 9c14adf1c59..00000000000 --- a/bdb/docs/api_cxx/txn_id.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - -
-
-DbTxn::id- |
-
-
- |
-#include <db_cxx.h> --u_int32_t -DbTxn::id(); -
The DbTxn::id method returns the unique transaction id associated with the -specified transaction. Locking calls made on behalf of this transaction -should use the value returned from DbTxn::id as the locker parameter -to the DbEnv::lock_get or DbEnv::lock_vec calls. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_prepare.html b/bdb/docs/api_cxx/txn_prepare.html deleted file mode 100644 index de7db8e7611..00000000000 --- a/bdb/docs/api_cxx/txn_prepare.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-DbTxn::prepare- |
-
-
- |
-#include <db_cxx.h> --int -DbTxn::prepare(); -
The DbTxn::prepare method initiates the beginning of a two-phase commit. -
In a distributed transaction environment, Berkeley DB can be used as a local -transaction manager. In this case, the distributed transaction manager -must send prepare messages to each local manager. The local -manager must then issue a DbTxn::prepare and await its successful -return before responding to the distributed transaction manager. Only -after the distributed transaction manager receives successful responses -from all of its prepare messages should it issue any -commit messages. -
In the case of nested transactions, preparing a parent transaction -causes all unresolved children of the parent transaction to be prepared. -
The DbTxn::prepare method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbTxn::prepare method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbTxn::prepare method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/txn_stat.html b/bdb/docs/api_cxx/txn_stat.html deleted file mode 100644 index 9644a6ae889..00000000000 --- a/bdb/docs/api_cxx/txn_stat.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - -
-
-DbEnv::txn_stat- |
-
-
- |
-#include <db_cxx.h> --extern "C" { - typedef void *(*db_malloc_fcn_type)(size_t); -}; -int -DbEnv::txn_stat(DB_TXN_STAT **statp, db_malloc_fcn_type db_malloc); -
The DbEnv::txn_stat method -creates a statistical structure and copies a pointer to it into a -user-specified memory location. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The transaction region statistics are stored in a structure of type -DB_TXN_STAT. The following DB_TXN_STAT fields will be filled in: -
The DbEnv::txn_stat method either returns a non-zero error value or throws an exception that -encapsulates a non-zero error value on failure, and returns 0 on success. -
The DbEnv::txn_stat method may fail and throw an exception or return a non-zero error for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv::txn_stat method may fail and either -return DB_RUNRECOVERY or throw an exception encapsulating -DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail -in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_cxx/what.html b/bdb/docs/api_cxx/what.html deleted file mode 100644 index 9e0410c7684..00000000000 --- a/bdb/docs/api_cxx/what.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - -
-
-DbException::what- |
-
-
- |
-#include <db_cxx.h> --virtual const char * -DbException::what() const; -
A DbException object contains an informational string and an errno. -The errno can be obtained by using DbException::get_errno. -The informational string can be obtained by using DbException::what. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_class.html b/bdb/docs/api_java/db_class.html deleted file mode 100644 index b03e55c1f69..00000000000 --- a/bdb/docs/api_java/db_class.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-Db- |
-
-
- |
-import com.sleepycat.db.*; --public class Db extends Object -{ - Db(DbEnv dbenv, int flags) - throws DbException; - ... -} -
This manual page describes the specific details of the Db class, -which is the center of access method activity. -
If no dbenv value is specified, the database is standalone, i.e., -it is not part of any Berkeley DB environment. -
If a dbenv value is specified, the database is created within the -specified Berkeley DB environment. The database access methods automatically -make calls to the other subsystems in Berkeley DB based on the enclosing -environment. For example, if the environment has been configured to use -locking, then the access methods will automatically acquire the correct -locks when reading and writing pages of the database. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_close.html b/bdb/docs/api_java/db_close.html deleted file mode 100644 index fcb8fde1dea..00000000000 --- a/bdb/docs/api_java/db_close.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - -
-
-Db.close- |
-
-
- |
-import com.sleepycat.db.*; --public int close(int flags) - throws DbException; -
The Db.close method flushes any cached database information to disk, -closes any open cursors, frees any allocated resources, and closes any -underlying files. Since key/data pairs are cached in memory, failing to -sync the file with the Db.close or Db.sync method may result -in inconsistent or lost information. -
The flags parameter must be set to 0 or the following value: -
The Db.DB_NOSYNC flag is a dangerous option. It should only be set -if the application is doing logging (with transactions) so that the -database is recoverable after a system or application crash, or if the -database is always generated from scratch after any system or application -crash. -
It is important to understand that flushing cached information to disk -only minimizes the window of opportunity for corrupted data. -While unlikely, it is possible for database corruption to happen if a -system or application crash occurs while writing data to the database. -To ensure that database corruption never occurs, applications must either: -use transactions and logging with automatic recovery, use logging and -application-specific recovery, or edit a copy of the database, -and, once all applications using the database have successfully called -Db.close, atomically replace the original database with the -updated copy. -
When multiple threads are using the Berkeley DB handle concurrently, only a single -thread may call the Db.close method. -
Once Db.close has been called, regardless of its return, the -Db handle may not be accessed again. - -
The Db.close method throws an exception that encapsulates a non-zero error value on -failure, and returns Db.DB_INCOMPLETE if the underlying database still has -dirty pages in the cache. (The only reason to return -Db.DB_INCOMPLETE is if another thread of control was writing pages -in the underlying database file at the same time as the -Db.close method was called. For this reason, a return of -Db.DB_INCOMPLETE can normally be ignored, or, in cases where it is -a possible return value, the Db.DB_NOSYNC option should probably -have been specified.) -
The Db.close method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.close method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.close method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_cursor.html b/bdb/docs/api_java/db_cursor.html deleted file mode 100644 index 2494aad58b7..00000000000 --- a/bdb/docs/api_java/db_cursor.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-Db.cursor- |
-
-
- |
-import com.sleepycat.db.*; --public Dbc cursor(DbTxn txnid, int flags) - throws DbException; -
The Db.cursor method -creates a cursor. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv.txn_begin, otherwise, NULL. -
If transaction protection is enabled, cursors must be opened and closed -within the context of a transaction, and the txnid parameter -specifies the transaction context in which the cursor may be used. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The Db.cursor method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.cursor method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The Db.cursor method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.cursor method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_del.html b/bdb/docs/api_java/db_del.html deleted file mode 100644 index 0a44190dd93..00000000000 --- a/bdb/docs/api_java/db_del.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-Db.del- |
-
-
- |
-import com.sleepycat.db.*; --public int del(DbTxn txnid, Dbt key, int flags) - throws DbException; -
The Db.del method removes key/data pairs from the database. The -key/data pair associated with the specified key is discarded from -the database. In the presence of duplicate key values, all records -associated with the designated key will be discarded. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv.txn_begin, otherwise, NULL. -
The flags parameter is currently unused, and must be set to 0. -
The Db.del method throws an exception that encapsulates a non-zero error value on -failure, and Db.DB_NOTFOUND if the specified key did not exist in -the file. -
The Db.del method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
If the operation was selected to resolve a deadlock, the -Db.del method will fail and -throw a DbDeadlockException exception. -
The Db.del method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.del method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_fd.html b/bdb/docs/api_java/db_fd.html deleted file mode 100644 index 77342c2c9a9..00000000000 --- a/bdb/docs/api_java/db_fd.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - -
-
-Db.fd- |
-
-
- |
-import com.sleepycat.db.*; --public int fd() - throws DbException; -
The Db.fd method -returns a file descriptor representative of the underlying database. -This method does not fit well into the Java framework and may be removed -in subsequent releases. -
The Db.fd method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.fd method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.fd method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_get.html b/bdb/docs/api_java/db_get.html deleted file mode 100644 index 8fd980e9260..00000000000 --- a/bdb/docs/api_java/db_get.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - -
-
-Db.get- |
-
-
- |
-import com.sleepycat.db.*; --public int get(DbTxn txnid, Dbt key, Dbt data, int flags) - throws DbException; -
The Db.get method retrieves key/data pairs from the database. The -byte array -and length of the data associated with the specified key are -returned in the structure referenced by data. -
In the presence of duplicate key values, Db.get will return the -first data item for the designated key. Duplicates are sorted by insert -order except where this order has been overridden by cursor operations. -Retrieval of duplicates requires the use of cursor operations. -See Dbc.get for details. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv.txn_begin, otherwise, NULL. -
The flags parameter must be set to 0 or one of the following -values: -
The data field of the specified key -must be a byte array large enough to hold a logical record -number (i.e., an int). -This record number determines the record to be retrieved. -
For Db.DB_SET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the DB_RECNUM flag. -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
As the Db.get interface will not hold locks across -Berkeley DB interface calls in non-transactional environments, the -Db.DB_RMW flag to the Db.get call is only meaningful in -the presence of transactions. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -the Db.get method returns Db.DB_KEYEMPTY. -
Otherwise, if the requested key is not in the database, the -Db.get function returns Db.DB_NOTFOUND. -
Otherwise, the Db.get method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.get method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
A record number of 0 was specified. -
The Db.DB_THREAD flag was specified to the -Db.open method and none of the Db.DB_DBT_MALLOC, -Db.DB_DBT_REALLOC or Db.DB_DBT_USERMEM flags were set in the -Dbt. -
If the operation was selected to resolve a deadlock, the -Db.get method will fail and -throw a DbDeadlockException exception. -
If the requested item could not be returned due to insufficient memory, -the Db.get method will fail and -throw a DbMemoryException exception. -
The Db.get method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.get method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_get_byteswapped.html b/bdb/docs/api_java/db_get_byteswapped.html deleted file mode 100644 index 1ef15479d99..00000000000 --- a/bdb/docs/api_java/db_get_byteswapped.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-Db.get_byteswapped- |
-
-
- |
-import com.sleepycat.db.*; --public boolean get_byteswapped(); -
The Db.get_byteswapped method returns -false -if the underlying database files were created on an architecture -of the same byte order as the current one, and -true -if they were not (i.e., big-endian on a little-endian machine or -vice-versa). This field may be used to determine if application -data needs to be adjusted for this architecture or not. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_get_type.html b/bdb/docs/api_java/db_get_type.html deleted file mode 100644 index cc10556190d..00000000000 --- a/bdb/docs/api_java/db_get_type.html +++ /dev/null @@ -1,72 +0,0 @@ - - - - -
-
-Db.get_type- |
-
-
- |
-import com.sleepycat.db.*; --public int get_type(); -
The Db.get_type method returns the type of the underlying access method -(and file format). It returns one of Db.DB_BTREE, -Db.DB_HASH or Db.DB_RECNO. This value may be used to -determine the type of the database after a return from Db.open -with the type argument set to Db.DB_UNKNOWN. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_join.html b/bdb/docs/api_java/db_join.html deleted file mode 100644 index 5bdd93fedde..00000000000 --- a/bdb/docs/api_java/db_join.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - -
-
-Db.join- |
-
-
- |
-import com.sleepycat.db.*; --public Dbc join(Dbc curslist[], int flags) - throws DbException; -
The Db.join method creates a specialized cursor for use in performing -joins on secondary indexes. For information on how to organize your data -to use this functionality, see Logical -join. -
The primary argument contains the Db handle of the primary -database, which is keyed by the data values found in entries in the -curslist. -
The curslist argument contains a null terminated array of cursors. -Each cursor must have been initialized to reference the key on which the -underlying database should be joined. Typically, this initialization is done -by a Dbc.get call with the Db.DB_SET flag specified. Once the -cursors have been passed as part of a curslist, they should not -be accessed or modified until the newly created join cursor has been closed, -or else inconsistent results may be returned. -
Joined values are retrieved by doing a sequential iteration over the first -cursor in the curslist argument, and a nested iteration over each -secondary cursor in the order they are specified in the curslist -argument. This requires database traversals to search for the current -datum in all the cursors after the first. For this reason, the best join -performance normally results from sorting the cursors from the one that -references the least number of data items to the one that references the -most. By default, Db.join does this sort on behalf of its caller. -
The flags parameter must be set to 0 or the following value: -
The returned cursor has the standard cursor functions: -
The flags parameter must be set to 0 or the following value: -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
For the returned join cursor to be used in a transaction protected manner, -the cursors listed in curslist must have been created within the -context of the same transaction. -
The Db.join method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.join method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The Db.join method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.join method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_key_range.html b/bdb/docs/api_java/db_key_range.html deleted file mode 100644 index dd68e0e1acf..00000000000 --- a/bdb/docs/api_java/db_key_range.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - -
-
-Db.key_range- |
-
-
- |
-import com.sleepycat.db.*; --public void key_range(DbTxn txnid - Dbt key, DbKeyRange key_range, int flags) - throws DbException; -
The Db.key_range method returns an estimate of the proportion of keys -that are less than, equal to and greater than the specified key. The -underlying database must be of type Btree. -
The information is returned in the key_range argument, which -contains three elements of type double, less, equal and -greater. Values are in the range of 0 to 1, e.g., if the field -less is 0.05, that indicates that 5% of the keys in the database -are less than the key argument. The value for equal will be zero -if there is no matching key and non-zero otherwise. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv.txn_begin, otherwise, NULL. -The Db.key_range method does not retain the locks it acquires for the -life of the transaction, so estimates may not be repeatable. -
The flags parameter is currently unused, and must be set to 0. -
The Db.key_range method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.key_range method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The underlying database was not of type Btree. -
If the operation was selected to resolve a deadlock, the -Db.key_range method will fail and -throw a DbDeadlockException exception. -
The Db.key_range method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.key_range method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_open.html b/bdb/docs/api_java/db_open.html deleted file mode 100644 index 5371e10bbc2..00000000000 --- a/bdb/docs/api_java/db_open.html +++ /dev/null @@ -1,179 +0,0 @@ - - - - -
-
-Db.open- |
-
-
- |
-import com.sleepycat.db.*; -import java.io.FileNotFoundException; --public void open(String file, - String database, int type, int flags, int mode) - throws DbException, FileNotFoundException; -
The currently supported Berkeley DB file formats (or access methods) -are Btree, Hash, Queue and Recno. The Btree format is a representation -of a sorted, balanced tree structure. The Hash format is an extensible, -dynamic hashing scheme. The Queue format supports fast access to -fixed-length records accessed by sequentially or logical record number. -The Recno format supports fixed- or variable-length records, accessed -sequentially or by logical record number, and optionally retrieved from -a flat text file. -
Storage and retrieval for the Berkeley DB access methods are based on key/data -pairs, see Dbt for more information. -
The Db.open interface opens the database represented by the -file and database arguments for both reading and writing. -The file argument is used as the name of a physical file on disk -that will be used to back the database. The database argument is -optional and allows applications to have multiple logical databases in a -single physical file. While no database argument needs to be -specified, it is an error to attempt to open a second database in a -file that was not initially created using a database name. -In-memory databases never intended to be preserved on disk may -be created by setting both the file and database arguments -to null. Note that in-memory databases can only ever be shared by -sharing the single database handle that created them, in circumstances -where doing so is safe. -
The type argument is of type int -and must be set to one of Db.DB_BTREE, Db.DB_HASH, -Db.DB_QUEUE, Db.DB_RECNO or Db.DB_UNKNOWN, except -that databases of type Db.DB_QUEUE are restricted to one per -file. If type is Db.DB_UNKNOWN, the database must -already exist and Db.open will automatically determine its type. -The Db.get_type method may be used to determine the underlying type of -databases opened using Db.DB_UNKNOWN. -
The flags and mode arguments specify how files will be opened -and/or created if they do not already exist. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The Db.DB_EXCL flag is only meaningful when specified with the -Db.DB_CREATE flag. -
Threading is always assumed in the Java API, so no special flags are -required, and Berkeley DB functions will always behave as if the -Db.DB_THREAD flag was specified. -
The Db.DB_TRUNCATE flag cannot be transaction protected, and it is -an error to specify it in a transaction protected environment. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by the access methods -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
Calling Db.open is a reasonably expensive operation, and -maintaining a set of open databases will normally be preferable to -repeatedly open and closing the database for each new query. -
The Db.open method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.open method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
-The Db.DB_THREAD flag was specified and spinlocks are not -implemented for this architecture. -
The Db.DB_THREAD flag was specified to Db.open, but was not -specified to the DbEnv.open call for the environment in which the -Db handle was created. -
A re_source file was specified with either the Db.DB_THREAD -flag or the provided database environment supports transaction -processing. -
The Db.open method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.open method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_put.html b/bdb/docs/api_java/db_put.html deleted file mode 100644 index 41fe6dcff9e..00000000000 --- a/bdb/docs/api_java/db_put.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - -
-
-Db.put- |
-
-
- |
-import com.sleepycat.db.*; --public int put(DbTxn txnid, Dbt key, Dbt data, int flags) - throws DbException; -
The Db.put method stores key/data pairs in the database. The default -behavior of the Db.put function is to enter the new key/data -pair, replacing any previously existing key if duplicates are disallowed, -or adding a duplicate data item if duplicates are allowed. If the database -supports duplicates, the Db.put method adds the new data value at the -end of the duplicate set. If the database supports sorted duplicates, -the new data value is inserted at the correct sorted location. -
If the file is being accessed under transaction protection, the -txnid parameter is a transaction ID returned from -DbEnv.txn_begin, otherwise, NULL. -
The flags parameter must be set to 0 or one of the following -values: -
There is a minor behavioral difference between the Recno and Queue access -methods for the Db.DB_APPEND flag. If a transaction enclosing a -Db.put operation with the Db.DB_APPEND flag aborts, the -record number may be decremented (and later re-allocated by a subsequent -Db.DB_APPEND operation) by the Recno access method, but will not be -decremented or re-allocated by the Queue access method. -
The Db.DB_NODUPDATA flag may not be specified to the Queue or Recno -access methods. -
Otherwise, the Db.put method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.put method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
A record number of 0 was specified. -
An attempt was made to add a record to a fixed-length database that was too -large to fit. -
An attempt was made to do a partial put. -
If the operation was selected to resolve a deadlock, the -Db.put method will fail and -throw a DbDeadlockException exception. -
The Db.put method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.put method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_remove.html b/bdb/docs/api_java/db_remove.html deleted file mode 100644 index d1238451cc4..00000000000 --- a/bdb/docs/api_java/db_remove.html +++ /dev/null @@ -1,104 +0,0 @@ - - - - -
-
-Db.remove- |
-
-
- |
-import com.sleepycat.db.*; -import java.io.FileNotFoundException; --public void remove(String file, String database, int flags) - throws DbException, FileNotFoundException; -
The Db.remove interface removes the database specified by the -file and database arguments. If no database is -specified, the physical file represented by file is removed, -incidentally removing all databases that it contained. -
If a physical file is being removed and logging is currently enabled in -the database environment, no database in the file may be open when the -Db.remove method is called. Otherwise, no reference count of database -use is maintained by Berkeley DB. Applications should not remove databases that -are currently in use. In particular, some architectures do not permit -the removal of files with open handles. On these architectures, attempts -to remove databases that are currently in use will fail. -
The flags parameter is currently unused, and must be set to 0. -
Once Db.remove has been called, regardless of its return, the -Db handle may not be accessed again. -
The Db.remove method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.remove method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
If the file or directory does not exist, the Db.remove method will -fail and -throw a FileNotFoundException exception. -
The Db.remove method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.remove method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_rename.html b/bdb/docs/api_java/db_rename.html deleted file mode 100644 index b34f20a26a5..00000000000 --- a/bdb/docs/api_java/db_rename.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - -
-
-Db.rename- |
-
-
- |
-import com.sleepycat.db.*; -import java.io.FileNotFoundException; --public void rename(String file, String database, String newname, int flags) - throws DbException, FileNotFoundException; -
The Db.rename interface renames the database specified by the -file and database arguments to newname. If no -database is specified, the physical file represented by -file is renamed, incidentally renaming all databases that it -contained. -
If a physical file is being renamed and logging is currently enabled in -the database environment, no database in the file may be open when the -Db.rename method is called. Otherwise, no reference count of database -use is maintained by Berkeley DB. Applications should not rename databases that -are currently in use. In particular, some architectures do not permit -renaming files with open handles. On these architectures, attempts to -rename databases that are currently in use will fail. -
The flags parameter is currently unused, and must be set to 0. -
Once Db.rename has been called, regardless of its return, the -Db handle may not be accessed again. -
The Db.rename method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.rename method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
If the file or directory does not exist, the Db.rename method will -fail and -throw a FileNotFoundException exception. -
The Db.rename method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.rename method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_append_recno.html b/bdb/docs/api_java/db_set_append_recno.html deleted file mode 100644 index 8a4d4a0df24..00000000000 --- a/bdb/docs/api_java/db_set_append_recno.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-Db.set_append_recno- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbAppendRecno -{ - public abstract void db_append_recno(Db db, Dbt data, int recno); - throws DbException; -} -public class Db -{ - public void set_append_recno(DbAppendRecno db_append_recno) - throws DbException; - ... -} -
When using the Db.DB_APPEND option of the Db.put method, -it may be useful to modify the stored data based on the generated key. -If a callback method is specified using the -Db.set_append_recno method, it will be called after the record number -has been selected but before the data has been stored. -The callback function must throw a DbException object to -encapsulate the error on failure. That object will be thrown to -caller of Db.put. -
The called function must take three arguments: a reference to the -enclosing database handle, the data Dbt to be stored and the -selected record number. The called function may then modify the data -Dbt. -
The Db.set_append_recno interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_append_recno method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_bt_compare.html b/bdb/docs/api_java/db_set_bt_compare.html deleted file mode 100644 index 2a2ea869b1e..00000000000 --- a/bdb/docs/api_java/db_set_bt_compare.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - -
-
-Db.set_bt_compare- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbBtreeCompare -{ - public abstract int bt_compare(Db db, Dbt dbt1, Dbt dbt2); -} -public class Db -{ - public void set_bt_compare(DbBtreeCompare bt_compare) - throws DbException; - ... -} -
Set the Btree key comparison function. The comparison function is -called when it is necessary to compare a key specified by the -application with a key currently stored in the tree. The first argument -to the comparison function is the Dbt representing the -application supplied key, the second is the current tree's key. -
The comparison function must return an integer value less than, equal -to, or greater than zero if the first key argument is considered to be -respectively less than, equal to, or greater than the second key -argument. In addition, the comparison function must cause the keys in -the database to be well-ordered. The comparison function -must correctly handle any key values used by the application (possibly -including zero-length keys). In addition, when Btree key prefix -comparison is being performed (see Db.set_bt_prefix for more -information), the comparison routine may be passed a prefix of any -database key. The data and size fields of the -Dbt are the only fields that may be used for the purposes of -this comparison. -
If no comparison function is specified, the keys are compared lexically, -with shorter keys collating before longer keys. The same comparison -method must be used each time a particular Btree is opened. -
The Db.set_bt_compare interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_bt_compare method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_bt_minkey.html b/bdb/docs/api_java/db_set_bt_minkey.html deleted file mode 100644 index dc7c1745123..00000000000 --- a/bdb/docs/api_java/db_set_bt_minkey.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - -
-
-Db.set_bt_minkey- |
-
-
- |
-import com.sleepycat.db.*; --public int set_bt_minkey(int bt_minkey) - throws DbException; -
Set the minimum number of keys that will be stored on any single -Btree page. -
This value is used to determine which keys will be stored on overflow -pages, i.e. if a key or data item is larger than the underlying database -page size divided by the bt_minkey value, it will be stored on -overflow pages instead of within the page itself. The bt_minkey -value specified must be at least 2; if bt_minkey is not explicitly -set, a value of 2 is used. -
The Db.set_bt_minkey interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_bt_minkey method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_bt_prefix.html b/bdb/docs/api_java/db_set_bt_prefix.html deleted file mode 100644 index a6e823969ca..00000000000 --- a/bdb/docs/api_java/db_set_bt_prefix.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - -
-
-Db.set_bt_prefix- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbBtreePrefix -{ - public abstract int bt_prefix(Db db, Dbt dbt1, Dbt dbt2); -} -public class Db -{ - public void set_bt_prefix(DbBtreePrefix bt_prefix) - throws DbException; - ... -} -
Set the Btree prefix function. The prefix function must return the -number of bytes of the second key argument that would be required by -the Btree key comparison function to determine the second key argument's -ordering relationship with respect to the first key argument. If the -two keys are equal, the key length should be returned. The prefix -function must correctly handle any key values used by the application -(possibly including zero-length keys). The data and -size fields of the Dbt are the only fields that may be -used for the purposes of this determination. -
The prefix function is used to determine the amount by which keys stored -on the Btree internal pages can be safely truncated without losing their -uniqueness. See the Btree -prefix comparison section of the Reference Guide for more details about -how this works. The usefulness of this is data dependent, but in some -data sets can produce significantly reduced tree sizes and search times. -
If no prefix function or key comparison function is specified by the -application, a default lexical comparison function is used as the prefix -function. If no prefix function is specified and a key comparison -function is specified, no prefix function is used. It is an error to -specify a prefix function without also specifying a key comparison -function. -
The Db.set_bt_prefix interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_bt_prefix method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_cachesize.html b/bdb/docs/api_java/db_set_cachesize.html deleted file mode 100644 index 67313aa5dd7..00000000000 --- a/bdb/docs/api_java/db_set_cachesize.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - - -
-
-Db.set_cachesize- |
-
-
- |
-import com.sleepycat.db.*; --public int set_cachesize(int gbytes, int bytes, int ncache) - throws DbException; -
Set the size of the database's shared memory buffer pool, i.e., the cache, -to gbytes gigabytes plus bytes. The cache should be the -size of the normal working data set of the application, with some small -amount of additional memory for unusual situations. (Note, the working -set is not the same as the number of simultaneously referenced pages, and -should be quite a bit larger!) -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
As databases opened within Berkeley DB environments use the cache specified to -the environment, it is an error to attempt to set a cache in a database -created within an environment. -
The Db.set_cachesize interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_cachesize method throws an exception that encapsulates a non-zero error value on -failure. -
The specified cache size was impossibly small. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_dup_compare.html b/bdb/docs/api_java/db_set_dup_compare.html deleted file mode 100644 index ea12dda35bc..00000000000 --- a/bdb/docs/api_java/db_set_dup_compare.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - -
-
-Db.set_dup_compare- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbDupCompare -{ - public abstract int dup_compare(Db db, Dbt dbt1, Dbt dbt2); -} -public class Db -{ - public void set_dup_compare(DbDupCompare dup_compare) - throws DbException; - ... -} -
Set the duplicate data item comparison function. The comparison function -is called when it is necessary to compare a data item specified by the -application with a data item currently stored in the tree. The first -argument to the comparison function is the Dbt representing the -application's data item, the second is the current tree's data item. -
The comparison function must return an integer value less than, equal -to, or greater than zero if the first data item argument is considered -to be respectively less than, equal to, or greater than the second data -item argument. In addition, the comparison function must cause the data -items in the set to be well-ordered. The comparison function -must correctly handle any data item values used by the application -(possibly including zero-length data items). The data and -size fields of the Dbt are the only fields that may be -used for the purposes of this comparison. -
If no comparison function is specified, the data items are compared -lexically, with shorter data items collating before longer data items. -The same duplicate data item comparison method must be used each time -a particular Btree is opened. -
The Db.set_dup_compare interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_dup_compare method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_errcall.html b/bdb/docs/api_java/db_set_errcall.html deleted file mode 100644 index 62f39f6b3ff..00000000000 --- a/bdb/docs/api_java/db_set_errcall.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - - -
-
-Db.set_errcall- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbErrcall -{ - public abstract void errcall(String errpfx, String msg); -} -public class Db -{ - public void set_errcall(DbErrcall errcall); - ... -} -
The Db.set_errcall method is used to enhance the mechanism for reporting error -messages to the application. The DbEnv.set_errcall method must be -called with a single object argument. The object's class must implement -the DbErrcall interface. In some cases, when an error occurs, Berkeley DB will -invoke the object's errcall() method with two arguments; the first is the -prefix string (as previously set by Db.set_errpfx or -DbEnv.set_errpfx), the second will be an error message string. -It is up to this method to display the message in an appropriate manner. -
Alternatively, you can use the DbEnv.set_error_stream method to display -the additional information via an output stream. You should not mix these -approaches. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
For Db handles opened inside of Berkeley DB environments, calling the -Db.set_errcall method affects the entire environment and is equivalent to calling -the DbEnv.set_errcall method. -
The Db.set_errcall interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_errpfx.html b/bdb/docs/api_java/db_set_errpfx.html deleted file mode 100644 index 36db5bd8af4..00000000000 --- a/bdb/docs/api_java/db_set_errpfx.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - -
-
-Db.set_errpfx- |
-
-
- |
-import com.sleepycat.db.*; --public void set_errpfx(String errpfx); -
Set the prefix string that appears before error messages issued by Berkeley DB. -
For Db handles opened inside of Berkeley DB environments, calling the -Db.set_errpfx method affects the entire environment and is equivalent to calling -the DbEnv.set_errpfx method. -
The Db.set_errpfx interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_feedback.html b/bdb/docs/api_java/db_set_feedback.html deleted file mode 100644 index b6dc64fc220..00000000000 --- a/bdb/docs/api_java/db_set_feedback.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - -
-
-Db.set_feedback- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbFeedback -{ - public abstract void db_feedback(Db db, int opcode, int pct); -} -public class Db -{ - public void set_feedback(DbFeedback db_feedback) - throws DbException; - ... -} -
Some operations performed by the Berkeley DB library can take non-trivial -amounts of time. The Db.set_feedback method can be used by -applications to monitor progress within these operations. -
When an operation is likely to take a long time, Berkeley DB will call the -specified callback method. This method must be declared with -three arguments: the first will be a reference to the enclosing database -handle, the second a flag value, and the third the percent of the -operation that has been completed, specified as an integer value between -0 and 100. It is up to the callback method to display this -information in an appropriate manner. -
The opcode argument may take on any of the following values: -
The Db.set_feedback interface may be used to configure Berkeley DB at any time -during the life of the application. -
The Db.set_feedback method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_flags.html b/bdb/docs/api_java/db_set_flags.html deleted file mode 100644 index 2a79213ea45..00000000000 --- a/bdb/docs/api_java/db_set_flags.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - -
-
-Db.set_flags- |
-
-
- |
-import com.sleepycat.db.*; --public void set_flags(int flags) - throws DbException; -
Calling Db.set_flags is additive, there is no way to clear flags. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The following flags may be specified for the Btree access method: -
Logical record numbers in Btree databases are mutable in the face of -record insertion or deletion. See the DB_RENUMBER flag in the Recno -access method information for further discussion. -
Maintaining record counts within a Btree introduces a serious point of -contention, namely the page locations where the record counts are stored. -In addition, the entire tree must be locked during both insertions and -deletions, effectively single-threading the tree for those operations. -Specifying DB_RECNUM can result in serious performance degradation for -some applications and data sets. -
It is an error to specify both DB_DUP and DB_RECNUM. -
The following flags may be specified for the Hash access method: -
There are no additional flags that may be specified for the Queue access -method. -
The following flags may be specified for the Recno access method: -
Using the Db.put or Dbc.put interfaces to create new -records will cause the creation of multiple records if the record number -is more than one greater than the largest record currently in the -database. For example, creating record 28, when record 25 was previously -the last record in the database, will create records 26 and 27 as well as -28. Attempts to retrieve records that were created in this manner will -result in an error return of Db.DB_KEYEMPTY. -
If a created record is not at the end of the database, all records -following the new record will be automatically renumbered upward by 1. -For example, the creation of a new record numbered 8 causes records -numbered 8 and greater to be renumbered upward by 1. If a cursor was -positioned to record number 8 or greater before the insertion, it will be -shifted upward 1 logical record, continuing to reference the same record -as it did before. -
For these reasons, concurrent access to a Recno database with the -Db.DB_RENUMBER flag specified may be largely meaningless, although -it is supported. -
The Db.set_flags interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_flags method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_h_ffactor.html b/bdb/docs/api_java/db_set_h_ffactor.html deleted file mode 100644 index c5d10aab05c..00000000000 --- a/bdb/docs/api_java/db_set_h_ffactor.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - -
-
-Db.set_h_ffactor- |
-
-
- |
-import com.sleepycat.db.*; --public void set_h_ffactor(int h_ffactor) - throws DbException; -
Set the desired density within the hash table. -
The density is an approximation of the number of keys allowed to -accumulate in any one bucket, determining when the hash table grows or -shrinks. If you know the average sizes of the keys and data in your -dataset, setting the fill factor can enhance performance. A reasonable -rule computing fill factor is to set it to: -
-(pagesize - 32) / (average_key_size + average_data_size + 8)
If no value is specified, the fill factor will be selected dynamically as -pages are filled. -
The Db.set_h_ffactor interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_h_ffactor method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_h_hash.html b/bdb/docs/api_java/db_set_h_hash.html deleted file mode 100644 index 89bccc1fbb9..00000000000 --- a/bdb/docs/api_java/db_set_h_hash.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - -
-
-Db.set_h_hash- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbHash -{ - public abstract int hash(Db db, byte[] data, int len); -} -public class Db -{ - public void set_h_hash(DbHash h_hash) - throws DbException; - ... -} -
Set a user defined hash method; if no hash method is specified, a default -hash method is used. Since no hash method performs equally well on all -possible data, the user may find that the built-in hash method performs -poorly with a particular data set. User specified hash functions must -take a pointer to a byte string and a length as arguments and return a -value of type -int. -The hash function must handle any key values used by the application -(possibly including zero-length keys). -
If a hash method is specified, Db.open will attempt to determine -if the hash method specified is the same as the one with which the database -was created, and will fail if it detects that it is not. -
The Db.set_h_hash interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_h_hash method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_h_nelem.html b/bdb/docs/api_java/db_set_h_nelem.html deleted file mode 100644 index 279e109abf7..00000000000 --- a/bdb/docs/api_java/db_set_h_nelem.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - -
-
-Db.set_h_nelem- |
-
-
- |
-import com.sleepycat.db.*; --public void set_h_nelem(int h_nelem) - throws DbException; -
Set an estimate of the final size of the hash table. -
If not set or set too low, hash tables will still expand gracefully -as keys are entered, although a slight performance degradation may be -noticed. -
The Db.set_h_nelem interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_h_nelem method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_lorder.html b/bdb/docs/api_java/db_set_lorder.html deleted file mode 100644 index 9f6ce37d996..00000000000 --- a/bdb/docs/api_java/db_set_lorder.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-Db.set_lorder- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lorder(int lorder) - throws DbException; -
Set the byte order for integers in the stored database metadata. The -number should represent the order as an integer, for example, big endian -order is the number 4,321, and little endian order is the number 1,234. -If lorder is not explicitly set, the host order of the machine -where the Berkeley DB library was compiled is used. -
The value of lorder is ignored except when databases are being -created. If a database already exists, the byte order it uses is -determined when the database is opened. -
The access methods provide no guarantees about the byte ordering of the -application data stored in the database, and applications are responsible -for maintaining any necessary ordering. -
The Db.set_lorder interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_lorder method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_pagesize.html b/bdb/docs/api_java/db_set_pagesize.html deleted file mode 100644 index 23c2462a0c0..00000000000 --- a/bdb/docs/api_java/db_set_pagesize.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-Db.set_pagesize- |
-
-
- |
-import com.sleepycat.db.*; --public void set_pagesize(long pagesize) - throws DbException; -
Set the size of the pages used to hold items in the database, in bytes. -The minimum page size is 512 bytes and the maximum page size is 64K bytes. -If the page size is not explicitly set, one is selected based on the -underlying filesystem I/O block size. The automatically selected size -has a lower limit of 512 bytes and an upper limit of 16K bytes. -
For information on tuning the Berkeley DB page size, see -Selecting a page size. -
The Db.set_pagesize interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_pagesize method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_q_extentsize.html b/bdb/docs/api_java/db_set_q_extentsize.html deleted file mode 100644 index 081c5b76c75..00000000000 --- a/bdb/docs/api_java/db_set_q_extentsize.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-Db.set_q_extentsize- |
-
-
- |
-import com.sleepycat.db.*; --public void set_q_extentsize(int extentsize) - throws DbException; -
Set the size of the extents used to hold pages in a Queue database, -specified as a number of pages. Each extent is created as a separate -physical file. If no extent size is set, the default behavior is to -create only a single underlying database file. -
For information on tuning the extent size, see -Selecting a extent size. -
The Db.set_q_extentsize interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_q_extentsize method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_re_delim.html b/bdb/docs/api_java/db_set_re_delim.html deleted file mode 100644 index dfe6bb848de..00000000000 --- a/bdb/docs/api_java/db_set_re_delim.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-Db.set_re_delim- |
-
-
- |
-import com.sleepycat.db.*; --public void set_re_delim(int re_delim) - throws DbException; -
Set the delimiting byte used to mark the end of a record in the backing -source file for the Recno access method. -
This byte is used for variable length records, if the re_source -file is specified. If the re_source file is specified and no -delimiting byte was specified, <newline> characters (i.e. -ASCII 0x0a) are interpreted as end-of-record markers. -
The Db.set_re_delim interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_re_delim method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_re_len.html b/bdb/docs/api_java/db_set_re_len.html deleted file mode 100644 index 34fa523b09a..00000000000 --- a/bdb/docs/api_java/db_set_re_len.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-Db.set_re_len- |
-
-
- |
-import com.sleepycat.db.*; --public void set_re_len(int re_len) - throws DbException; -
For the Queue access method, specify that the records are of length -re_len. -
For the Recno access method, specify that the records are fixed-length, -not byte delimited, and are of length re_len. -
Any records added to the database that are less than re_len bytes -long are automatically padded (see Db.set_re_pad for more -information). -
Any attempt to insert records into the database that are greater than -re_len bytes long will cause the call to fail immediately and -return an error. -
The Db.set_re_len interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_re_len method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_re_pad.html b/bdb/docs/api_java/db_set_re_pad.html deleted file mode 100644 index 118130c54b3..00000000000 --- a/bdb/docs/api_java/db_set_re_pad.html +++ /dev/null @@ -1,81 +0,0 @@ - - - - -
-
-Db.set_re_pad- |
-
-
- |
-import com.sleepycat.db.*; --public void set_re_pad(int re_pad) - throws DbException; -
Set the padding character for short, fixed-length records for the Queue -and Recno access methods. -
If no pad character is specified, <space> characters (i.e., -ASCII 0x20) are used for padding. -
The Db.set_re_pad interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_re_pad method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_set_re_source.html b/bdb/docs/api_java/db_set_re_source.html deleted file mode 100644 index 7ff82a20480..00000000000 --- a/bdb/docs/api_java/db_set_re_source.html +++ /dev/null @@ -1,123 +0,0 @@ - - - - -
-
-Db.set_re_source- |
-
-
- |
-import com.sleepycat.db.*; --public void set_re_source(String re_source) - throws DbException; -
Set the underlying source file for the Recno access method. The purpose -of the re_source value is to provide fast access and modification -to databases that are normally stored as flat text files. -
If the re_source field is set, it specifies an underlying flat -text database file that is read to initialize a transient record number -index. In the case of variable length records, the records are separated -as specified by Db.set_re_delim. For example, standard UNIX -byte stream files can be interpreted as a sequence of variable length -records separated by <newline> characters. -
In addition, when cached data would normally be written back to the -underlying database file (e.g., the Db.close or Db.sync -methods are called), the in-memory copy of the database will be written -back to the re_source file. -
By default, the backing source file is read lazily, i.e., records are not -read from the file until they are requested by the application. -If multiple processes (not threads) are accessing a Recno database -concurrently and either inserting or deleting records, the backing source -file must be read in its entirety before more than a single process -accesses the database, and only that process should specify the backing -source file as part of the Db.open call. See the Db.DB_SNAPSHOT -flag for more information. -
Reading and writing the backing source file specified by re_source -cannot be transactionally protected because it involves filesystem -operations that are not part of the Db transaction methodology. -For this reason, if a temporary database is used to hold the records, -i.e., a null was specified as the file argument to Db.open, -it is possible to lose the contents of the re_source file, e.g., -if the system crashes at the right instant. -If a file is used to hold the database, i.e., a file name was specified -as the file argument to Db.open, normal database -recovery on that file can be used to prevent information loss, -although it is still possible that the contents of re_source -will be lost if the system crashes. -
The re_source file must already exist (but may be zero-length) when -Db.open is called. -
It is not an error to specify a read-only re_source file when -creating a database, nor is it an error to modify the resulting database. -However, any attempt to write the changes to the backing source file using -either the Db.sync or Db.close methods will fail, of course. -Specify the Db.DB_NOSYNC flag to the Db.close method to stop it -from attempting to write the changes to the backing file, instead, they -will be silently discarded. -
For all of the above reasons, the re_source field is generally -used to specify databases that are read-only for Db applications, -and that are either generated on the fly by software tools, or modified -using a different mechanism, e.g., a text editor. -
The Db.set_re_source interface may only be used to configure Berkeley DB before -the Db.open interface is called. -
The Db.set_re_source method throws an exception that encapsulates a non-zero error value on -failure. -
Called after Db.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_stat.html b/bdb/docs/api_java/db_stat.html deleted file mode 100644 index 197ba19138d..00000000000 --- a/bdb/docs/api_java/db_stat.html +++ /dev/null @@ -1,185 +0,0 @@ - - - - -
-
-Db.stat- |
-
-
- |
-import com.sleepycat.db.*; --public Object Db.stat(int flags); -
The Db.stat method creates a statistical structure and -fills it with statistics for the database. -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The flags parameter must be set to 0 or the following value: -
This option is only available for Recno databases, or Btree databases -where the underlying database was created with the Db.DB_RECNUM -flag. -
The Db.stat method may access all of the pages in the database, -incurring a severe performance penalty as well as possibly flushing the -underlying buffer pool. -
In the presence of multiple threads or processes accessing an active -database, the information returned by Db.stat may be out-of-date. -
If the database was not opened readonly and the Db.DB_CACHED_COUNTS -flag was not specified, the cached key and record numbers will be updated -after the statistical information has been gathered. -
The Db.stat method cannot be transaction protected. For this reason, -it should be called in a thread of control that has no open cursors or -active transactions. -
The Db.stat method throws an exception that encapsulates a non-zero error value on -failure. -
In the case of a Hash database, -the statistics are returned in an instance of DbHashStat. The data -fields are available from DbHashStat: -
In the case of a Btree or Recno database, -the statistics are returned in an instance of DbBtreeStat. The data -fields are available from DbBtreeStat: -
For the Recno Access Method, the number of records in the database. -
For the Recno Access Method, the number of records in the database. If -the database has been configured to not re-number records during -deletion, the number of records will only reflect undeleted records. -
In the case of a Queue database, -the statistics are returned in an instance of DbQueueStat. The data -fields are available from DbQueueStat: -
The Db.stat method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.stat method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.stat method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_sync.html b/bdb/docs/api_java/db_sync.html deleted file mode 100644 index 5162bd13d55..00000000000 --- a/bdb/docs/api_java/db_sync.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - -
-
-Db.sync- |
-
-
- |
-import com.sleepycat.db.*; --public int sync(int flags) - throws DbException; -
The Db.sync method flushes any cached information to disk. -
If the database is in memory only, the Db.sync method has no effect and -will always succeed. -
The flags parameter is currently unused, and must be set to 0. -
See Db.close for a discussion of Berkeley DB and cached data. -
The Db.sync method throws an exception that encapsulates a non-zero error value on -failure, and returns Db.DB_INCOMPLETE if the underlying database still has -dirty pages in the cache. (The only reason to return -Db.DB_INCOMPLETE is if another thread of control was writing pages -in the underlying database file at the same time as the -Db.sync method was being called. For this reason, a return of -Db.DB_INCOMPLETE can normally be ignored, or, in cases where it is -a possible return value, there may be no reason to call -Db.sync.) -
The Db.sync method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The Db.sync method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.sync method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_upgrade.html b/bdb/docs/api_java/db_upgrade.html deleted file mode 100644 index 6f6da088c35..00000000000 --- a/bdb/docs/api_java/db_upgrade.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - -
-
-Db.upgrade- |
-
-
- |
-import com.sleepycat.db.*; --public void upgrade(String file, int flags) - throws DbException; -
The Db.upgrade method upgrades all of the databases included in the -file file, if necessary. If no upgrade is necessary, -Db.upgrade always returns success. -
Database upgrades are done in place and are destructive, e.g., if pages -need to be allocated and no disk space is available, the database may be -left corrupted. Backups should be made before databases are upgraded. -See Upgrading databases for more -information. -
Unlike all other database operations, Db.upgrade may only be done -on a system with the same byte-order as the database. -
The flags parameter must be set to 0 or one of the following -values: -
As part of the upgrade from the Berkeley DB 3.0 release to the 3.1 release, the -on-disk format of duplicate data items changed. To correctly upgrade the -format requires applications specify if duplicate data items in the -database are sorted or not. Specifying the Db.DB_DUPSORT flag -informs Db.upgrade that the duplicates are sorted, otherwise they -are assumed to be unsorted. Incorrectly specifying the value of this flag -may lead to database corruption. -
Further, because the Db.upgrade method upgrades a physical file -(including all of the databases it contains), it is not possible to use -Db.upgrade to upgrade files where some of the databases it -includes have sorted duplicate data items and some of the databases it -includes have unsorted duplicate data items. If the file does not have -more than a single database, or the databases do not support duplicate -data items, or all of the databases that support duplicate data items -support the same style of duplicates (either sorted or unsorted), -Db.upgrade will work correctly as long as the Db.DB_DUPSORT -flag is correctly specified. Otherwise, the file cannot be upgraded using -Db.upgrade, and must be upgraded manually by dumping and -re-loading the databases. -
The Db.upgrade method throws an exception that encapsulates a non-zero error value on -failure. -
The Db.upgrade method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The database is not in the same byte-order as the system. -
The Db.upgrade method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.upgrade method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/db_verify.html b/bdb/docs/api_java/db_verify.html deleted file mode 100644 index e2702028305..00000000000 --- a/bdb/docs/api_java/db_verify.html +++ /dev/null @@ -1,140 +0,0 @@ - - - - -
-
-Db.verify- |
-
-
- |
-import com.sleepycat.db.*; --public void verify(String file, - String database, java.io.OutputStream outfile, int flags) - throws DbException; -
The Db.verify method verifies the integrity of all databases in the -file specified by the file argument, and optionally outputs the databases' -key/data pairs to a file stream. -
The flags parameter must be set to 0 or one of the following -values: -
Because the key/data pairs are output in page order as opposed to the sort -order used by db_dump, using Db.verify to dump key/data -pairs normally produces less than optimal loads for Btree databases. -
In addition, the following flags may be set by bitwise inclusively OR'ing them into the -flags parameter: -
The Db.verify method normally verifies that btree keys and duplicate -items are correctly sorted and hash keys are correctly hashed. If the -file being verified contains multiple databases using differing sorting -or hashing algorithms, some of them must necessarily fail database -verification as only one sort order or hash function can be specified -before Db.verify is called. To verify files with multiple -databases having differing sorting orders or hashing functions, first -perform verification of the file as a whole by using the -Db.DB_NOORDERCHK flag, and then individually verify the sort order -and hashing function for each database in the file using the -Db.DB_ORDERCHKONLY flag. -
When this flag is specified, a database argument should also be -specified, indicating the database in the physical file which is to be -checked. This flag is only safe to use on databases that have already -successfully been verified using Db.verify with the -Db.DB_NOORDERCHK flag set. -
The database argument must be set to null except when the -Db.DB_ORDERCHKONLY flag is set. -
The Db.verify method throws an exception that encapsulates a non-zero error value on -failure, and Db.DB_VERIFY_BAD if a database is corrupted. When the -Db.DB_SALVAGE flag is specified, the Db.DB_VERIFY_BAD return -means that all key/data pairs in the file may not have been successfully -output. -
The Db.verify method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The Db.verify method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Db.verify method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_class.html b/bdb/docs/api_java/dbc_class.html deleted file mode 100644 index 61f6b9ec2b6..00000000000 --- a/bdb/docs/api_java/dbc_class.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - -
-
-Dbc- |
-
-
- |
-import com.sleepycat.db.*; --public class Dbc extends Object { ... } -
This manual page describes the specific details of the Dbc class, -which provides cursor support for the access methods in Db. -
The Dbc functions are the library interface supporting sequential -access to the records stored by the access methods of the Berkeley DB library. -Cursors are created by calling the Db.cursor method which returns a - Dbc object. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_close.html b/bdb/docs/api_java/dbc_close.html deleted file mode 100644 index c8ad0570296..00000000000 --- a/bdb/docs/api_java/dbc_close.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-Dbc.close- |
-
-
- |
-import com.sleepycat.db.*; --public void close() - throws DbException; -
The Dbc.close method discards the cursor. -
It is possible for the Dbc.close method to return -Db.DB_LOCK_DEADLOCK, signaling that any enclosing transaction should -be aborted. If the application is already intending to abort the -transaction, this error should be ignored, and the application should -proceed. -
Once Dbc.close has been called, regardless of its return, the -cursor handle may not be used again. -
The Dbc.close method throws an exception that encapsulates a non-zero error value on -failure. -
The Dbc.close method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The cursor was previously closed. -
If the operation was selected to resolve a deadlock, the -Dbc.close method will fail and -throw a DbDeadlockException exception. -
The Dbc.close method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc.close method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_count.html b/bdb/docs/api_java/dbc_count.html deleted file mode 100644 index 324ee148550..00000000000 --- a/bdb/docs/api_java/dbc_count.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - -
-
-Dbc.count- |
-
-
- |
-import com.sleepycat.db.*; --public int count(int flags) - throws DbException; -
The Dbc.count method returns a count of the number of duplicate data -items for the key referenced by the -cursor. -If the underlying database does not support duplicate data items the call -will still succeed and a count of 1 will be returned. -
The flags parameter is currently unused, and must be set to 0. -
If the cursor argument is not yet initialized, the Dbc.count method throws an exception that encapsulates EINVAL. -
Otherwise, the Dbc.count method throws an exception that encapsulates a non-zero error value on -failure. -
The Dbc.count method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc.count method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_del.html b/bdb/docs/api_java/dbc_del.html deleted file mode 100644 index eb4a32362cf..00000000000 --- a/bdb/docs/api_java/dbc_del.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-Dbc.del- |
-
-
- |
-import com.sleepycat.db.*; --public int del(int flags) - throws DbException; -
The Dbc.del method deletes the key/data pair currently referenced by -the cursor. -
The flags parameter is currently unused, and must be set to 0. -
The cursor position is unchanged after a delete, and subsequent calls to -cursor functions expecting the cursor to reference an existing key will -fail. -
If the element has already been deleted, Dbc.del will return -Db.DB_KEYEMPTY. -
If the cursor is not yet initialized, the Dbc.del method throws an exception that encapsulates EINVAL. -
Otherwise, the Dbc.del method throws an exception that encapsulates a non-zero error value on -failure. -
The Dbc.del method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
If the operation was selected to resolve a deadlock, the -Dbc.del method will fail and -throw a DbDeadlockException exception. -
The Dbc.del method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc.del method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_dup.html b/bdb/docs/api_java/dbc_dup.html deleted file mode 100644 index f02afbb7350..00000000000 --- a/bdb/docs/api_java/dbc_dup.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - -
-
-Dbc.dup- |
-
-
- |
-import com.sleepycat.db.*; --public Dbc dup(int flags) - throws DbException; -
The Dbc.dup method creates a new cursor that uses the same transaction -and locker ID as the original cursor. This is useful when an application -is using locking and requires two or more cursors in the same thread of -control. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
When using the Berkeley DB Concurrent Data Store product, there can be only one active write cursor -at a time. For this reason, attempting to duplicate a cursor for which -the Db.DB_WRITECURSOR flag was specified during creation will return -an error. -
If the cursor argument is not yet initialized, the Dbc.dup method throws an exception that encapsulates EINVAL. -
Otherwise, the Dbc.dup method throws an exception that encapsulates a non-zero error value on -failure. -
The Dbc.dup method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The cursor argument was created using the -Db.DB_WRITECURSOR flag in the Berkeley DB Concurrent Data Store product. -
The Dbc.dup method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc.dup method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_get.html b/bdb/docs/api_java/dbc_get.html deleted file mode 100644 index 8213c5b51fc..00000000000 --- a/bdb/docs/api_java/dbc_get.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - -
-
-Dbc.get- |
-
-
- |
-import com.sleepycat.db.*; --public int get(Dbt key, Dbt data, int flags) - throws DbException; -
The Dbc.get method retrieves key/data pairs from the database. The -byte array and length of the key -are returned in the object referenced by key (except for the case -of the Db.DB_SET flag where the key object is unchanged), -and the byte array and length of -the data are returned in the object referenced by data. -
Modifications to the database during a sequential scan will be reflected -in the scan, i.e. records inserted behind a cursor will not be returned -while records inserted in front of a cursor will be returned. -
In Queue and Recno databases, missing entries (i.e., entries that were -never explicitly created or that were created and then deleted), will be -skipped during a sequential scan. -
If multiple threads or processes insert items into the same database file -without using locking, the results are undefined. -For more detail, -see Cursor stability. -
The flags parameter must be set to one of the following values: -
If the cursor key/data pair was deleted, Dbc.get will return -Db.DB_KEYEMPTY. -
If the cursor is not yet initialized, the Dbc.get method throws an exception that encapsulates EINVAL. -
If the database is a Queue or Recno database, Dbc.get using the -Db.DB_FIRST (Db.DB_LAST) flags will ignore any keys that exist -but were never explicitly created by the application or were created and -later deleted. -
If the database is empty, Dbc.get will return Db.DB_NOTFOUND. -
For Db.DB_GET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the Db.DB_RECNUM -flag. -
For Db.DB_JOIN_ITEM to be specified, the underlying cursor must have -been returned from the Db.join method. -
If the database is a Queue or Recno database, Dbc.get using the -Db.DB_NEXT (Db.DB_PREV) flag will skip any keys that exist but -were never explicitly created by the application or were created and later -deleted. -
If the cursor is already on the last (first) record in the database, -Dbc.get will return Db.DB_NOTFOUND. -
If the cursor is not yet initialized, the Dbc.get method throws an exception that encapsulates EINVAL. -
If the database is a Queue or Recno database, Dbc.get using the -Db.DB_NEXT_NODUP (Db.DB_PREV_NODUP) flags will ignore any keys -that exist but were never explicitly created by the application or were -created and later deleted. -
If no non-duplicate key/data pairs occur after (before) the cursor -position in the database, Dbc.get will return Db.DB_NOTFOUND. -
In the presence of duplicate key values, Dbc.get will return the -first data item for the given key. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -Dbc.get will return Db.DB_KEYEMPTY. -
If no matching keys are found, Dbc.get will return -Db.DB_NOTFOUND. -
For Db.DB_SET_RECNO to be specified, the underlying database must be -of type Btree and it must have been created with the Db.DB_RECNUM -flag. -
In addition, the following flag may be set by bitwise inclusively OR'ing it into the -flags parameter: -
Otherwise, the Dbc.get method throws an exception that encapsulates a non-zero error value on -failure. -
If Dbc.get fails for any reason, the state of the cursor will be -unchanged. -
The Dbc.get method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The specified cursor was not currently initialized. -
If the operation was selected to resolve a deadlock, the -Dbc.get method will fail and -throw a DbDeadlockException exception. -
If the requested item could not be returned due to insufficient memory, -the Dbc.get method will fail and -throw a DbMemoryException exception. -
The Dbc.get method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc.get method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbc_put.html b/bdb/docs/api_java/dbc_put.html deleted file mode 100644 index a2969e15956..00000000000 --- a/bdb/docs/api_java/dbc_put.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - -
-
-Dbc.put- |
-
-
- |
-import com.sleepycat.db.*; --public void put(Dbt key, Dbt data, int flags) - throws DbException; -
The Dbc.put method stores key/data pairs into the database. -
The flags parameter must be set to one of the following values: -
In the case of the Recno access method, it is an error to specify -Db.DB_AFTER if the underlying Recno database was not created with -the Db.DB_RENUMBER flag. If the Db.DB_RENUMBER flag was -specified, a new key is created, all records after the inserted item -are automatically renumbered, and the key of the new record is returned -in the structure referenced by the parameter key. The initial -value of the key parameter is ignored. See Db.open -for more information. -
The Db.DB_AFTER flag may not be specified to the Queue access method. -
If the current cursor record has already been deleted and the underlying -access method is Hash, Dbc.put will return Db.DB_NOTFOUND. -If the underlying access method is Btree or Recno, the operation will -succeed. -
If the cursor is not yet initialized or a duplicate sort function has been -specified, the Dbc.put function will return EINVAL. -
In the case of the Recno access method, it is an error to specify -Db.DB_BEFORE if the underlying Recno database was not created with -the Db.DB_RENUMBER flag. If the Db.DB_RENUMBER flag was -specified, a new key is created, the current record and all records -after it are automatically renumbered, and the key of the new record is -returned in the structure referenced by the parameter key. The -initial value of the key parameter is ignored. See -Db.open for more information. -
The Db.DB_BEFORE flag may not be specified to the Queue access method. -
If the current cursor record has already been deleted and the underlying -access method is Hash, Dbc.put will return Db.DB_NOTFOUND. -If the underlying access method is Btree or Recno, the operation will -succeed. -
If the cursor is not yet initialized or a duplicate sort function has been -specified, Dbc.put will return EINVAL. -
If a duplicate sort function has been specified and the data item of the -current referenced key/data pair does not compare equally to the data -parameter, Dbc.put will return EINVAL. -
If the current cursor record has already been deleted and the underlying -access method is Hash, Dbc.put will return Db.DB_NOTFOUND. -If the underlying access method is Btree, Queue or Recno, the operation -will succeed. -
If the cursor is not yet initialized, Dbc.put will return EINVAL. -
If the underlying database supports duplicate data items, and if the -key already exists in the database and a duplicate sort function has -been specified, the inserted data item is added in its sorted location. -If the key already exists in the database and no duplicate sort function -has been specified, the inserted data item is added as the first of the -data items for that key. -
The Db.DB_KEYFIRST flag may not be specified to the Queue or Recno -access methods. -
If the underlying database supports duplicate data items, and if the -key already exists in the database and a duplicate sort function has -been specified, the inserted data item is added in its sorted location. -If the key already exists in the database, and no duplicate sort -function has been specified, the inserted data item is added as the last -of the data items for that key. -
The Db.DB_KEYLAST flag may not be specified to the Queue or Recno -access methods. -
The Db.DB_NODUPDATA flag may not be specified to the Queue or Recno -access methods. -
Otherwise, the Dbc.put method throws an exception that encapsulates a non-zero error value on -failure. -
If Dbc.put fails for any reason, the state of the cursor will be -unchanged. If Dbc.put succeeds and an item is inserted into the -database, the cursor is always positioned to reference the newly inserted -item. -
The Dbc.put method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The Db.DB_BEFORE or Db.DB_AFTER flags were specified, and the -underlying access method is Queue. -
An attempt was made to add a record to a fixed-length database that was too -large to fit. -
If the operation was selected to resolve a deadlock, the -Dbc.put method will fail and -throw a DbDeadlockException exception. -
The Dbc.put method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the Dbc.put method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbenv_class.html b/bdb/docs/api_java/dbenv_class.html deleted file mode 100644 index f610cf67015..00000000000 --- a/bdb/docs/api_java/dbenv_class.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - -
-
-DbEnv- |
-
-
- |
-import com.sleepycat.db.*; --public class DbEnv extends Object -{ - public DbEnv(int flags); - ... -} -
This manual page describes the specific details of the DbEnv -class, which is the center of the Berkeley DB environment. -
The following flags value may be specified: -
The Db.DB_CLIENT flag indicates to the system that this environment -is remote on a server. The use of this flag causes the environment -methods to use functions that call a server instead of local functions. -Prior to making any environment or database method calls, the -application must call the DbEnv.set_server function to establish -the connection to the server. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/dbt_class.html b/bdb/docs/api_java/dbt_class.html deleted file mode 100644 index 1df9cbb59d1..00000000000 --- a/bdb/docs/api_java/dbt_class.html +++ /dev/null @@ -1,227 +0,0 @@ - - - - -
-
-Dbt- |
-
-
- |
-import com.sleepycat.db.*; --public class Dbt extends Object -{ - public Dbt(byte[] data); - public Dbt(byte[] data, int off, int len); -
- public void set_data(byte[] data); - public byte[] get_data(); -
- public void set_offset(int off); - public int get_offset(); -
- public int get_size(); - public void set_size(int size); -
- public int get_ulen(); - public void set_ulen(int ulen); -
- public int get_dlen(); - public void set_dlen(int dlen); -
- public int get_doff(); - public void set_doff(int doff); -
- public int get_flags(); - public void set_flags(int flags); -
- public void set_recno_key_data(int recno); - public int get_recno_key_data(); -} -
This manual page describes the specific details of the Dbt class, -used to encode keys and data items in a database. - -
Storage and retrieval for the Db access methods are based on -key/data pairs. Both key and data items are represented by Dbt -objects. Key and data byte strings may reference strings of zero length -up to strings of essentially unlimited length. See -Database limits for more -information. -
The Dbt class provides simple access to an underlying data structure, -whose elements can be examined or changed using the set_ or -get_ methods. The remainder of the manual page sometimes refers -to these accesses using the underlying name, e.g., simply ulen -instead of Dbt.get_ulen and Dbt.set_ulen. -Dbt can be subclassed, providing a way to associate -with it additional data, or references to other structures. -
The constructors set all elements of the underlying structure to zero. -The constructor with one argument has the effect of setting all elements -to zero except for the specified data and size elements. -The constructor with three arguments has has the additional effect of -only using the portion of the array specified by the size and offset. -
In the case where the flags structure element is 0, when being -provided a key or data item by the application, the Berkeley DB package expects -the data object to be set to a byte array of size bytes. -When returning a key/data item to the application, the Berkeley DB package will -store into the data object a byte array of size bytes. -During a get operation, one of the Db.DB_DBT_MALLOC, -Db.DB_DBT_REALLOC or Db.DB_DBT_USERMEM flags must be -specified. -
The elements of the structure underlying the Dbt class are defined as follows: -
Note that applications can determine the length of a record by setting -the ulen to 0 and checking the return value found in size. -See the Db.DB_DBT_USERMEM flag for more information. -
This element is accessed using -Dbt.get_ulen and Dbt.set_ulen. -
The flags value must be set by bitwise inclusively OR'ing together one or more of the -following values. -
If Db.DB_DBT_MALLOC is specified, Berkeley DB allocates a properly sized -byte array to contain the data. This can be convenient if you know little -about the nature of the data, specifically the size of data in the -database. However, if your application makes repeated calls to retrieve -keys or data, you may notice increased garbage collection due to this -allocation. If you know the maximum size of data you are retrieving, you -might decrease the memory burden and speed your application by allocating -your own byte array and using Db.DB_DBT_USERMEM. Even if you don't -know the maximum size, you can use this option and reallocate your array -whenever your retrieval API call -throws a DbMemoryException. -
It is an error to specify more than one of Db.DB_DBT_MALLOC, -Db.DB_DBT_REALLOC and Db.DB_DBT_USERMEM. -
It is an error to specify more than one of Db.DB_DBT_MALLOC, -Db.DB_DBT_REALLOC and Db.DB_DBT_USERMEM. -
If Db.DB_DBT_USERMEM is specified, the data field of the Dbt -must be set to an appropriately sized byte array. -
It is an error to specify more than one of Db.DB_DBT_MALLOC, -Db.DB_DBT_REALLOC and Db.DB_DBT_USERMEM. -
If Db.DB_DBT_MALLOC or Db.DB_DBT_REALLOC is specified, Berkeley DB -allocates a properly sized byte array to contain the data. This can be -convenient if you know little about the nature of the data, specifically -the size of data in the database. However, if your application makes -repeated calls to retrieve keys or data, you may notice increased garbage -collection due to this allocation. If you know the maximum size of data -you are retrieving, you might decrease the memory burden and speed your -application by allocating your own byte array and using -Db.DB_DBT_USERMEM. Even if you don't know the maximum size, you can -use this option and reallocate your array whenever your retrieval API call -throws a DbMemoryException. -
For example, if the data portion of a retrieved record was 100 bytes, -and a partial retrieval was done using a Dbt having a dlen -field of 20 and a doff field of 85, the get call would succeed, -the data field would reference the last 15 bytes of the record, -and the size field would be set to 15. -
If the calling application is doing a put, the dlen bytes starting -doff bytes from the beginning of the specified key's data record -are replaced by the data specified by the data and size -objects. -If dlen is smaller than size, the record will grow, and if -dlen is larger than size, the record will shrink. -If the specified bytes do not exist, the record will be extended using nul -bytes as necessary, and the put call will succeed. -
It is an error to attempt a partial put using the Db.put -method in a database that supports duplicate records. -Partial puts in databases supporting duplicate records must be done -using a Dbc method. -
It is an error to attempt a partial put with differing dlen and -size values in Queue or Recno databases with fixed-length records. -
For example, if the data portion of a retrieved record was 100 bytes, -and a partial put was done using a Dbt having a dlen -field of 20, a doff field of 85, and a size field of 30, -the resulting record would be 115 bytes in length, where the last 30 -bytes would be those specified by the put call. -
Although Java normally maintains proper alignment of byte arrays, the -set_offset method can be used to specify unaligned addresses. Unaligned -address accesses that are not supported by the underlying hardware may be -reported as an exception, or may stop the running Java program. - -
In all cases for the Queue and Recno access methods, and when calling the -Db.get and Dbc.get functions with the -Db.DB_SET_RECNO flag specified, the data -field of the key must be a four byte array, large enough to store an int. -The Dbt.set_recno_key_data method can be used to set the value of -the array. An int is a 32-bit type, -(which limits the number of logical records in a Queue or Recno database, -and the maximum logical record which may be directly retrieved from a -Btree database, to 4,294,967,296). The size field of the key -should be the size of that type, i.e., -4. -
Logical record numbers are 1-based, not 0-based, i.e., the first record -in the database is record number 1. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/deadlock_class.html b/bdb/docs/api_java/deadlock_class.html deleted file mode 100644 index b41c5649dcf..00000000000 --- a/bdb/docs/api_java/deadlock_class.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - -
-
-DbDeadlockException- |
-
-
- |
-import com.sleepycat.db.*; --public class DbDeadlockException extends DbException { ... } -
This manual page describes the DbDeadlockException class and -how it is used by the various Db* classes. -
A DbDeadlockException is thrown when multiple threads competing -for a lock are deadlocked. One of the threads' transactions is selected -for termination, and a DbDeadlockException is thrown to that thread. -
See DbEnv.set_lk_detect for more information. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_close.html b/bdb/docs/api_java/env_close.html deleted file mode 100644 index 9650c83ed85..00000000000 --- a/bdb/docs/api_java/env_close.html +++ /dev/null @@ -1,82 +0,0 @@ - - - - -
-
-DbEnv.close- |
-
-
- |
-import com.sleepycat.db.*; --public void close(int flags) - throws DbException; -
The DbEnv.close method closes the Berkeley DB environment, freeing any -allocated resources and closing any underlying subsystems. -
Calling DbEnv.close does not imply closing any databases that were -opened in the environment. -
The flags parameter is currently unused, and must be set to 0. -
Where the environment was initialized with the Db.DB_INIT_LOCK flag, -calling DbEnv.close does not release any locks still held by the -closing process, providing functionality for long-lived locks. -
Where the environment was initialized with the Db.DB_INIT_MPOOL -flag, calling DbEnv.close implies calls to DbMpoolFile.close for -any remaining open files in the memory pool that were returned to this -process by calls to DbMpoolFile.open. It does not imply a call to -DbMpoolFile.sync for those files. -
Where the environment was initialized with the Db.DB_INIT_TXN flag, -calling DbEnv.close aborts any uncommitted transactions. -(Applications are should not depend on this behavior. If the process' has -already closed a database handle which is necessary to abort an -uncommitted transaction, the Berkeley DB environment must then require that -recovery be run before further operations are done, since once a -transaction exists that cannot be committed or aborted, no future -checkpoint can ever succeed.) -
In multi-threaded applications, only a single thread may call -DbEnv.close. -
Once DbEnv.close has been called, regardless of its return, -the Berkeley DB environment handle may not be accessed again. -
The DbEnv.close method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.close method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.close method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_open.html b/bdb/docs/api_java/env_open.html deleted file mode 100644 index 3a1c2503633..00000000000 --- a/bdb/docs/api_java/env_open.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - -
-
-DbEnv.open- |
-
-
- |
-import com.sleepycat.db.*; -import java.io.FileNotFoundException; --public void open(String db_home, int flags, int mode) - throws DbException, FileNotFoundException; -
The DbEnv.open method is the interface for opening the Berkeley DB -environment. It provides a structure for creating a consistent -environment for processes using one or more of the features of Berkeley DB. -
The db_home argument to DbEnv.open (and file name -resolution in general) is described in -Berkeley DB File Naming. -
The flags argument specifies the subsystems that are initialized -and how the application's environment affects Berkeley DB file naming, among -other things. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
As there are a large number of flags that can be specified, they have been -grouped together by functionality. The first group of flags indicate -which of the Berkeley DB subsystems should be initialized: -
Access method calls are largely unchanged when using this flag, although -any cursors through which update operations (e.g., Dbc.put, -Dbc.del) will be made must have the Db.DB_WRITECURSOR value -set in the flags parameter to the cursor call that creates the cursor. -See Db.cursor for more information. -
The log is stored in one or more files in the environment directory. -Each file is named using the format log.NNNNNNNNNN, where -NNNNNNNNNN is the sequence number of the file within the log. -For further information, see -Log File Limits. -
If the log region is being created and log files are already present, the -log files are reviewed and subsequent log writes are appended -to the end of the log, rather than overwriting current log entries. -
The second group of flags govern what recovery, if any, is performed when -the environment is initialized: -
A standard part of the recovery process is to remove the existing Berkeley DB -environment and create a new one in which to perform recovery. If the -thread of control performing recovery does not specify the correct region -initialization information (e.g., the correct memory pool cache size), -the result can be an application running in an environment with incorrect -cache and other subsystem sizes. For this reason, the thread of control -performing recovery should either specify correct configuration -information before calling the DbEnv.open method, or it should remove -the environment after recovery is completed, leaving creation of the -correctly sized environment to a subsequent call to DbEnv.open. -
All Berkeley DB recovery processing must be single-threaded, that is, only a -single thread of control may perform recovery or access a Berkeley DB -environment while recovery is being performed. As it is not an error to -specify Db.DB_RECOVER for an environment for which no recovery is -required, it is reasonable programming practice for the thread of control -responsible for performing recovery and creating the environment to always -specify the Db.DB_RECOVER flag during startup. -
The DbEnv.open function returns successfully if Db.DB_RECOVER -or Db.DB_RECOVER_FATAL is specified and no log files exist, so it is -necessary to ensure all necessary log files are present before running -recovery. For further information, consult db_archive and -db_recover. -
The third group of flags govern file naming extensions in the environment: -
Finally, there are a few additional, unrelated flags: -
This flag should not be specified if more than a single process is -accessing the environment, as it is likely to cause database corruption -and unpredictable behavior, e.g., if both a server application and the -Berkeley DB utility db_stat will access the environment, the -Db.DB_PRIVATE flag should not be specified. -
Threading is always assumed in the Java API, so no special flags are -required and Berkeley DB functions will always behave as if the Db.DB_THREAD -flag was specified. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by Berkeley DB -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
The DbEnv.open method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.open method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
-The Db.DB_THREAD flag was specified and spinlocks are not -implemented for this architecture. -
The DB_HOME or TMPDIR environment variables were set but empty. -
An incorrectly formatted NAME VALUE entry or line was found. -
If the file or directory does not exist, the DbEnv.open method will -fail and -throw a FileNotFoundException exception. -
The DbEnv.open method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.open method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_remove.html b/bdb/docs/api_java/env_remove.html deleted file mode 100644 index acfaf39761e..00000000000 --- a/bdb/docs/api_java/env_remove.html +++ /dev/null @@ -1,129 +0,0 @@ - - - - -
-
-DbEnv.remove- |
-
-
- |
-import com.sleepycat.db.*; -import java.io.FileNotFoundException; --public void remove(String db_home, int flags) - throws DbException, FileNotFoundException; -
The DbEnv.remove method destroys a Berkeley DB environment, if it is not -currently in use. The environment regions, including any backing files, -are removed. Any log or database files and the environment directory are -not removed. -
The db_home argument to DbEnv.remove is described in -Berkeley DB File Naming. -
If there are processes that have called DbEnv.open without -calling DbEnv.close (i.e., there are processes currently using -the environment), DbEnv.remove will fail without further action, -unless the Db.DB_FORCE flag is set, in which case -DbEnv.remove will attempt to remove the environment regardless -of any processes still using it. -
The result of attempting to forcibly destroy the environment when it is -in use is unspecified. Processes using an environment often maintain open -file descriptors for shared regions within it. On UNIX systems, the -environment removal will usually succeed and processes that have already -joined the region will continue to run in that region without change, -however processes attempting to join the environment will either fail or -create new regions. On other systems (e.g., Windows/NT), where the -unlink(2) system call will fail if any process has an open -file descriptor for the file, the region removal will fail. -
Calling DbEnv.remove should not be necessary for most applications, -as the Berkeley DB environment is cleaned up as part of normal database recovery -procedures, however, applications may wish to call DbEnv.remove -as part of application shutdown to free up system resources. -Specifically, when the Db.DB_SYSTEM_MEM flag was specified to -DbEnv.open, it may be useful to call DbEnv.remove in order -to release system shared memory segments that have been allocated. -
In the case of catastrophic or system failure, database recovery must be -performed (see db_recover), or the Db.DB_RECOVER and -Db.DB_RECOVER_FATAL flags to DbEnv.open must be specified -when the environment is re-opened. Alternatively, if recovery is not -required because no database state is maintained across failures, and -the Db.DB_SYSTEM_MEM flag was not specified when the environment -was created, it is possible to clean up an environment by removing all -of the files in the environment directory that begin with the string -prefix "__db", as no backing files are created in any other directory. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
In multi-threaded applications, only a single thread may call -DbEnv.remove. -
A DbEnv handle which has already been used to open an -environment should not be used to call the DbEnv.remove method, a new -DbEnv handle should be created for that purpose. -
Once DbEnv.remove has been called, regardless of its return, -the Berkeley DB environment handle may not be accessed again. -
The DbEnv.remove method throws an exception that encapsulates a non-zero error value on -failure. -
If the file or directory does not exist, the DbEnv.remove method will -fail and -throw a FileNotFoundException exception. -
The DbEnv.remove method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.remove method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_cachesize.html b/bdb/docs/api_java/env_set_cachesize.html deleted file mode 100644 index af31e44f91d..00000000000 --- a/bdb/docs/api_java/env_set_cachesize.html +++ /dev/null @@ -1,86 +0,0 @@ - - - - - -
-
-DbEnv.set_cachesize- |
-
-
- |
-import com.sleepycat.db.*; --public int set_cachesize(int gbytes, int bytes, in ncache) - throws DbException; -
Set the size of the database's shared memory buffer pool, i.e., the cache, -to gbytes gigabytes plus bytes. The cache should be the -size of the normal working data set of the application, with some small -amount of additional memory for unusual situations. (Note, the working -set is not the same as the number of simultaneously referenced pages, and -should be quite a bit larger!) -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
The DbEnv.set_cachesize interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_cachesize method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's cache size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_cachesize", one or more whitespace characters, -and the three arguments specified to this interface, separated by whitespace -characters, for example, "set_cachesize 1 500 2". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
The specified cache size was impossibly small. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_data_dir.html b/bdb/docs/api_java/env_set_data_dir.html deleted file mode 100644 index 52fc159e77a..00000000000 --- a/bdb/docs/api_java/env_set_data_dir.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DbEnv.set_data_dir- |
-
-
- |
-import com.sleepycat.db.*; --public void set_data_dir(String dir) - throws DbException; -
Set the path of a directory to be used as the location of the access -method database files. Paths specified to the Db.open function -will be searched relative to this path. Paths set using this interface -are additive, and specifying more than one will result in each specified -directory being searched for database files. If any directories are -specified, created database files will always be created in the first path -specified. -
If no database directories are specified, database files can only exist -in the environment home directory. See Berkeley DB File Naming for more information. -
For the greatest degree of recoverability from system or application -failure, database files and log files should be located on separate -physical devices. -
The DbEnv.set_data_dir interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_data_dir method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's data directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_data_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_errcall.html b/bdb/docs/api_java/env_set_errcall.html deleted file mode 100644 index 596de47137d..00000000000 --- a/bdb/docs/api_java/env_set_errcall.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - - -
-
-DbEnv.set_errcall- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbErrcall -{ - public abstract void errcall(String errpfx, String msg); -} -public class DbEnv -{ - public void set_errcall(DbErrcall errcall); - ... -} -
The DbEnv.set_errcall method is used to enhance the mechanism for reporting error -messages to the application. The DbEnv.set_errcall method must be -called with a single object argument. The object's class must implement -the DbErrcall interface. In some cases, when an error occurs, Berkeley DB will -invoke the object's errcall() method with two arguments; the first is the -prefix string (as previously set by Db.set_errpfx or -DbEnv.set_errpfx), the second will be an error message string. -It is up to this method to display the message in an appropriate manner. -
Alternatively, you can use the DbEnv.set_error_stream method to display -the additional information via an output stream. You should not mix these -approaches. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
The DbEnv.set_errcall interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_error_stream.html b/bdb/docs/api_java/env_set_error_stream.html deleted file mode 100644 index 18f44c08d7d..00000000000 --- a/bdb/docs/api_java/env_set_error_stream.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DbEnv.set_error_stream- |
-
-
- |
-import com.sleepycat.db.*; --public void Db.set_error_stream(OutputStream s) - throws DbException -
When an error occurs in the Berkeley DB library, an exception is thrown. In -some cases, however, the errno value may be insufficient to -completely describe the cause of the error, especially during initial -application debugging. -
The DbEnv.set_error_stream method is used to enhance the mechanism for -reporting error messages to the application by setting a OutputStream -to be used for displaying additional Berkeley DB error messages. In some cases, -when an error occurs, Berkeley DB will output an additional error message to -the specified stream. -
The error message will consist of the prefix string and a colon -(":") (if a prefix string was previously specified using -DbEnv.set_errpfx), an error string, and a trailing -<newline> character. -
Alternatively, you can use the DbEnv.set_errcall method to capture the -additional error information in a way that does not use output streams. -You should not mix these approaches. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_errpfx.html b/bdb/docs/api_java/env_set_errpfx.html deleted file mode 100644 index aca43448c8b..00000000000 --- a/bdb/docs/api_java/env_set_errpfx.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - -
-
-DbEnv.set_errpfx- |
-
-
- |
-import com.sleepycat.db.*; --public void set_errpfx(String errpfx); -
Set the prefix string that appears before error messages issued by Berkeley DB. -
The DbEnv.set_errpfx interface may be used to configure Berkeley DB at any time -during the life of the application. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_feedback.html b/bdb/docs/api_java/env_set_feedback.html deleted file mode 100644 index 1b5310e2537..00000000000 --- a/bdb/docs/api_java/env_set_feedback.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - -
-
-DbEnv.set_feedback- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbEnvFeedback -{ - public abstract void db_feedback(DbEnv dbenv, int opcode, int pct); -} -public class DbEnv -{ - public void set_feedback(DbEnvFeedback db_feedback) - throws DbException; - ... -} -
Some operations performed by the Berkeley DB library can take non-trivial -amounts of time. The DbEnv.set_feedback method can be used by -applications to monitor progress within these operations. -
When an operation is likely to take a long time, Berkeley DB will call the -specified callback method. This method must be declared with -three arguments: the first will be a reference to the enclosing -environment, the second a flag value, and the third the percent of the -operation that has been completed, specified as an integer value between -0 and 100. It is up to the callback method to display this -information in an appropriate manner. -
The opcode argument may take on any of the following values: -
The DbEnv.set_feedback interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv.set_feedback method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_flags.html b/bdb/docs/api_java/env_set_flags.html deleted file mode 100644 index d371429e0ae..00000000000 --- a/bdb/docs/api_java/env_set_flags.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-DbEnv.set_flags- |
-
-
- |
-import com.sleepycat.db.*; --public void set_flags(int flags, int onoff) - throws DbException; -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -If onoff is zero, the specified flags are cleared, otherwise they -are set. -
The number of transactions that are potentially at risk is governed by -how often the log is checkpointed (see db_checkpoint for more -information) and how many log updates can fit on a single log page. -
The DbEnv.set_flags method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's flag values may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_flags", one or more whitespace characters, -and the interface flag argument as a string, for example, "set_flags -DB_TXN_NOSYNC". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lg_bsize.html b/bdb/docs/api_java/env_set_lg_bsize.html deleted file mode 100644 index 1f3725f6eb5..00000000000 --- a/bdb/docs/api_java/env_set_lg_bsize.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv.set_lg_bsize- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lg_bsize(int lg_bsize) - throws DbException; -
Set the size of the in-memory log buffer, in bytes. By default, or if -the value is set to 0, a size of 32K is used. -
Log information is stored in-memory until the storage space fills up -or transaction commit forces the information to be flushed to stable -storage. In the presence of long-running transactions or transactions -producing large amounts of data, larger buffer sizes can increase -throughput. -
The DbEnv.set_lg_bsize interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lg_bsize method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's log buffer size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_bsize", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lg_dir.html b/bdb/docs/api_java/env_set_lg_dir.html deleted file mode 100644 index 6633ee5d820..00000000000 --- a/bdb/docs/api_java/env_set_lg_dir.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - -
-
-DbEnv.set_lg_dir- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lg_dir(String dir) - throws DbException; -
The path of a directory to be used as the location of logging files. -Log files created by the Log Manager subsystem will be created in this -directory. -
If no logging directory is specified, log files are created in the -environment home directory. See Berkeley DB File Naming for more information. -
For the greatest degree of recoverability from system or application -failure, database files and log files should be located on separate -physical devices. -
The DbEnv.set_lg_dir interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lg_dir method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's logging directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lg_max.html b/bdb/docs/api_java/env_set_lg_max.html deleted file mode 100644 index fea4163bec0..00000000000 --- a/bdb/docs/api_java/env_set_lg_max.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv.set_lg_max- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lg_max(int lg_max) - throws DbException; -
Set the maximum size of a single file in the log, in bytes. Because -DbLsn file offsets are unsigned 4-byte values, the set value may -not be larger than the maximum unsigned 4-byte value. By default, or if -the value is set to 0, a size of 10MB is used. -
See Log File Limits -for more information. -
The DbEnv.set_lg_max interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lg_max method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's log file size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lg_max", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
The specified log file size was too large. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lk_conflicts.html b/bdb/docs/api_java/env_set_lk_conflicts.html deleted file mode 100644 index 3ad5c6173c9..00000000000 --- a/bdb/docs/api_java/env_set_lk_conflicts.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
-
-DbEnv.set_lk_conflicts- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lk_conflicts(byte[][] conflicts) - throws DbException; -
Set the locking conflicts matrix. -A non-0 value for the array element: -
-conflicts[requested_mode][held_mode]
indicates that requested_mode and held_mode conflict. The -not-granted mode must be represented by 0. -
If no conflicts value is specified, the conflicts array -db_rw_conflicts is used; see Standard Lock Modes for a description of that array. -
The DbEnv.set_lk_conflicts interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lk_conflicts method throws an exception that encapsulates a non-zero error value on -failure. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lk_detect.html b/bdb/docs/api_java/env_set_lk_detect.html deleted file mode 100644 index cf3dd087177..00000000000 --- a/bdb/docs/api_java/env_set_lk_detect.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - -
-
-DbEnv.set_lk_detect- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lk_detect(int detect) - throws DbException; -
Set if the deadlock detector is to be run whenever a lock conflict occurs, -and specify which transaction should be aborted in the case of a deadlock. -The specified value must be one of the following list: -
The DbEnv.set_lk_detect interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lk_detect method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's deadlock detector configuration may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_detect", one or more whitespace characters, -and the interface detect argument as a string, for example, -"set_lk_detect DB_LOCK_OLDEST". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lk_max.html b/bdb/docs/api_java/env_set_lk_max.html deleted file mode 100644 index 1e2a928901b..00000000000 --- a/bdb/docs/api_java/env_set_lk_max.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - -
-
-DbEnv.set_lk_max- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lk_max(int max) - throws DbException; -
The DbEnv.set_lk_max method interface has been deprecated in favor of -the DbEnv.set_lk_max_locks, DbEnv.set_lk_max_lockers, -and DbEnv.set_lk_max_objects methods. Please update your applications. -
Set each of the maximum number of locks, lockers and lock objects -supported by the Berkeley DB lock subsystem to max. This value is -used by DbEnv.open to estimate how much space to allocate for -various lock-table data structures. For specific information on -configuring the size of the lock subsystem, see -Configuring locking: sizing the -system. -
The DbEnv.set_lk_max interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lk_max method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's maximum number of locks may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max", one or more whitespace characters, -and the number of locks. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lk_max_lockers.html b/bdb/docs/api_java/env_set_lk_max_lockers.html deleted file mode 100644 index 500244beee5..00000000000 --- a/bdb/docs/api_java/env_set_lk_max_lockers.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - -
-
-DbEnv.set_lk_max_lockers- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lk_max_lockers(int max) - throws DbException; -
Set the maximum number of simultaneous locking entities supported by -the Berkeley DB lock subsystem. This value is used by DbEnv.open to -estimate how much space to allocate for various lock-table data -structures. For specific information on configuring the size of the -lock subsystem, see -Configuring locking: sizing the system. -
The DbEnv.set_lk_max_lockers interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lk_max_lockers method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's maximum number of lockers may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_lockers", one or more whitespace characters, -and the number of lockers. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lk_max_locks.html b/bdb/docs/api_java/env_set_lk_max_locks.html deleted file mode 100644 index 88a5100aaef..00000000000 --- a/bdb/docs/api_java/env_set_lk_max_locks.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DbEnv.set_lk_max_locks- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lk_max_locks(int max) - throws DbException; -
Set the maximum number of locks supported by the Berkeley DB lock subsystem. -This value is used by DbEnv.open to estimate how much space to -allocate for various lock-table data structures. For specific -information on configuring the size of the lock subsystem, see -Configuring locking: sizing the system. -
The DbEnv.set_lk_max_locks interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lk_max_locks method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's maximum number of locks may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_locks", one or more whitespace characters, -and the number of locks. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_lk_max_objects.html b/bdb/docs/api_java/env_set_lk_max_objects.html deleted file mode 100644 index b31ebefbf21..00000000000 --- a/bdb/docs/api_java/env_set_lk_max_objects.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - -
-
-DbEnv.set_lk_max_objects- |
-
-
- |
-import com.sleepycat.db.*; --public void set_lk_max_objects(int max) - throws DbException; -
Set the maximum number of simultaneously locked objects supported by -the Berkeley DB lock subsystem. This value is used by DbEnv.open to -estimate how much space to allocate for various lock-table data -structures. For specific information on configuring the size of the -lock subsystem, see -Configuring locking: sizing the system. -
The DbEnv.set_lk_max_objects interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_lk_max_objects method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's maximum number of objects may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_lk_max_objects", one or more whitespace characters, -and the number of objects. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_mp_mmapsize.html b/bdb/docs/api_java/env_set_mp_mmapsize.html deleted file mode 100644 index ef1d5b14ef1..00000000000 --- a/bdb/docs/api_java/env_set_mp_mmapsize.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -
-
-DbEnv.set_mp_mmapsize- |
-
-
- |
-import com.sleepycat.db.*; --public void set_mp_mmapsize(long mmapsize) - throws DbException; -
Files that are opened read-only in the pool (and that satisfy a few other -criteria) are, by default, mapped into the process address space instead -of being copied into the local cache. This can result in better-than-usual -performance, as available virtual memory is normally much larger than the -local cache, and page faults are faster than page copying on many systems. -However, in the presence of limited virtual memory it can cause resource -starvation, and in the presence of large databases, it can result in immense -process sizes. -
Set the maximum file size, in bytes, for a file to be mapped into the -process address space. If no value is specified, it defaults to 10MB. -
The DbEnv.set_mp_mmapsize interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_mp_mmapsize method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's maximum mapped file size may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_mp_mmapsize", one or more whitespace characters, -and the size in bytes. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_mutexlocks.html b/bdb/docs/api_java/env_set_mutexlocks.html deleted file mode 100644 index e098987701e..00000000000 --- a/bdb/docs/api_java/env_set_mutexlocks.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-DbEnv.set_mutexlocks- |
-
-
- |
-import com.sleepycat.db.*; --public void set_mutexlocks(int do_lock) - throws DbException; -
Toggle mutex locks. Setting do_lock to a false value causes -Berkeley DB to grant all requested mutual exclusion mutexes without regard -for their availability. -
This functionality should never be used for any other purpose than -debugging. -
The DbEnv.set_mutexlocks interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv.set_mutexlocks method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_pageyield.html b/bdb/docs/api_java/env_set_pageyield.html deleted file mode 100644 index f67f3a88805..00000000000 --- a/bdb/docs/api_java/env_set_pageyield.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DbEnv.set_pageyield- |
-
-
- |
-import com.sleepycat.db.*; --static int -DbEnv.set_pageyield(int pageyield); - throws DbException; -
Yield the processor whenever requesting a page from the cache. Setting -pageyield to a true value causes Berkeley DB to yield the processor -any time a thread requests a page from the cache. -
The DbEnv.set_pageyield interface affects the entire application, not a single -database or database environment. -
While the DbEnv.set_pageyield interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
This functionality should never be used for any other purpose than stress -testing. -
The DbEnv.set_pageyield interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv.set_pageyield method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_panicstate.html b/bdb/docs/api_java/env_set_panicstate.html deleted file mode 100644 index d8b38ee2f6d..00000000000 --- a/bdb/docs/api_java/env_set_panicstate.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - -
-
-DbEnv.set_panicstate- |
-
-
- |
-import com.sleepycat.db.*; --static int -DbEnv.set_panicstate(int panic); - throws DbException; -
Toggle the Berkeley DB panic state. Setting panic to a true value -causes Berkeley DB to refuse attempts to call Berkeley DB functions with the -Db.DB_RUNRECOVERY error return. -
The DbEnv.set_panicstate interface affects the entire application, not a single -database or database environment. -
While the DbEnv.set_panicstate interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
The DbEnv.set_panicstate method throws an exception that encapsulates a non-zero error value on -failure. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_rec_init.html b/bdb/docs/api_java/env_set_rec_init.html deleted file mode 100644 index 430c33a02af..00000000000 --- a/bdb/docs/api_java/env_set_rec_init.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - -
-
-DbEnv.set_recovery_init- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbRecoveryInit -{ - public abstract int db_recovery_init_fcn(DbEnv dbenv); -} -public class DbEnv -{ - public void set_recovery_init(DbRecoveryInit db_recovery_init_fcn) - throws DbException; - ... -} -
Applications installing application-specific recovery methods need -to be called before Berkeley DB performs recovery so they may add their recovery -methods to Berkeley DB's. -
The DbEnv.set_recovery_init method supports this functionality. The -db_recovery_init_fcn method must be declared with one -argument, a reference to the enclosing Berkeley DB environment. This -method will be called after the DbEnv.open has been called, -but before recovery is started. -
If the db_recovery_init_fcn method returns a non-zero value, -no recovery will be performed and DbEnv.open will return the same -value to its caller. -
The DbEnv.set_recovery_init interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_recovery_init method throws an exception that encapsulates a non-zero error value on -failure. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_region_init.html b/bdb/docs/api_java/env_set_region_init.html deleted file mode 100644 index f4f5d256278..00000000000 --- a/bdb/docs/api_java/env_set_region_init.html +++ /dev/null @@ -1,78 +0,0 @@ - - - - -
-
-DbEnv.set_region_init- |
-
-
- |
-import com.sleepycat.db.*; --static int -DbEnv.set_region_init(int region_init); - throws DbException; -
Page-fault shared regions into memory when initially creating or joining -a Berkeley DB environment. In some applications, the expense of page-faulting -the shared memory regions can affect performance, e.g., when the -page-fault occurs while holding a lock, other lock requests can convoy -and overall throughput may decrease. Setting region_init to a -true value specifies that shared regions be read or written, as -appropriate, when the region is joined by the application. This forces -the underlying virtual memory and file systems to instantiate both the -necessary memory and the necessary disk space. This can also avoid -out-of-disk space failures later on. -
The DbEnv.set_region_init interface affects the entire application, not a single -database or database environment. -
While the DbEnv.set_region_init interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
The DbEnv.set_region_init method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's initial behavior with respect to shared memory regions may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_region_init", one or more whitespace characters, -and the string "1". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_server.html b/bdb/docs/api_java/env_set_server.html deleted file mode 100644 index a0ffeefe35f..00000000000 --- a/bdb/docs/api_java/env_set_server.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DbEnv.set_server- |
-
-
- |
-import com.sleepycat.db.*; --public void set_server(String host, - long cl_timeout, long sv_timeout, int flags) - throws DbException; -
Connects to the DB server on the indicated hostname and sets up a channel -for communication. -
The cl_timeout argument specifies the number of seconds the client -should wait for results to come back from the server. Once the timeout -has expired on any communication with the server, Db.DB_NOSERVER will -be returned. If this value is zero, a default timeout is used. -
The sv_timeout argument specifies the number of seconds the server -should allow a client connection to remain idle before assuming that -client is gone. Once that timeout has been reached, the server releases -all resources associated with that client connection. Subsequent attempts -by that client to communicate with the server result in -Db.DB_NOSERVER_ID indicating that an invalid identifier has been -given to the server. This value can be considered a hint to the server. -The server may alter this value based on its own policies or allowed -values. If this value is zero, a default timeout is used. -
The flags parameter is currently unused, and must be set to 0. -
When the DbEnv.set_server method has been called, any subsequent calls -to Berkeley DB library interfaces may return either DB_NOSERVER or -DB_NOSERVER_ID. -
The DbEnv.set_server method throws an exception that encapsulates a non-zero error value on -failure. -
dbenv_set_server -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_shm_key.html b/bdb/docs/api_java/env_set_shm_key.html deleted file mode 100644 index 12a65c92251..00000000000 --- a/bdb/docs/api_java/env_set_shm_key.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
-
-DbEnv.set_shm_key- |
-
-
- |
-import com.sleepycat.db.*; --public void set_shm_key(long shm_key) - throws DbException; -
Specify a base segment ID for Berkeley DB environment shared memory regions -created in system memory on VxWorks or systems supporting X/Open-style -shared memory interfaces, e.g., UNIX systems supporting -shmget(2) and related System V IPC interfaces. -
This base segment ID will be used when Berkeley DB shared memory regions are -first created. It will be incremented a small integer value each time -a new shared memory region is created, that is, if the base ID is 35, -the first shared memory region created will have a segment ID of 35 and -the next one a segment ID between 36 and 40 or so. A Berkeley DB environment -always creates a master shared memory region, plus an additional shared -memory region for each of the subsystems supported by the environment -(locking, logging, memory pool and transaction), plus an additional -shared memory region for each additional memory pool cache that is -supported. Already existing regions with the same segment IDs will be -removed. See Shared Memory Regions -for more information. -
The intent behind this interface is two-fold: without it, applications -have no way to ensure that two Berkeley DB applications don't attempt to use -the same segment IDs when creating different Berkeley DB environments. In -addition, by using the same segment IDs each time the environment is -created, previously created segments will be removed, and the set of -segments on the system will not grow without bound. -
The DbEnv.set_shm_key interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_shm_key method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's base segment ID may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_shm_key", one or more whitespace characters, -and the ID. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_tas_spins.html b/bdb/docs/api_java/env_set_tas_spins.html deleted file mode 100644 index 64654ebc96a..00000000000 --- a/bdb/docs/api_java/env_set_tas_spins.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - -
-
-DbEnv.set_tas_spins- |
-
-
- |
-import com.sleepycat.db.*; --static int -DbEnv.set_tas_spins(u_int32_t tas_spins); - throws DbException; -
Specify that test-and-set mutexes should spin tas_spins times -without blocking. The value defaults to 1 on uniprocessor systems and -to 50 times the number of processors on multiprocessor systems. -
The DbEnv.set_tas_spins interface affects the entire application, not a single -database or database environment. -
While the DbEnv.set_tas_spins interface may be used to configure Berkeley DB at any time -during the life of the application, it should normally be called before -making any calls to the db_env_create or db_create methods. -
The DbEnv.set_tas_spins method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's test-and-set spin count may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tas_spins", one or more whitespace characters, -and the number of spins. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_tmp_dir.html b/bdb/docs/api_java/env_set_tmp_dir.html deleted file mode 100644 index 8c3c4b899c0..00000000000 --- a/bdb/docs/api_java/env_set_tmp_dir.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - -
-
-DbEnv.set_tmp_dir- |
-
-
- |
-import com.sleepycat.db.*; --public void set_tmp_dir(String dir) - throws DbException; -
The path of a directory to be used as the location of temporary files. -The files created to back in-memory access method databases will be -created relative to this path. These temporary files can be quite large, -depending on the size of the database. -
If no directories are specified, the following alternatives are checked -in the specified order. The first existing directory path is used for -all temporary files. -
Note: environment variables are only checked if one of the -Db.DB_USE_ENVIRON or Db.DB_USE_ENVIRON_ROOT flags were -specified. -
Note: the GetTempPath interface is only checked on Win/32 platforms. -
The DbEnv.set_tmp_dir interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_tmp_dir method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's temporary file directory may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tmp_dir", one or more whitespace characters, -and the directory name. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_tx_max.html b/bdb/docs/api_java/env_set_tx_max.html deleted file mode 100644 index d1a57f5c856..00000000000 --- a/bdb/docs/api_java/env_set_tx_max.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DbEnv.set_tx_max- |
-
-
- |
-import com.sleepycat.db.*; --public void set_tx_max(int tx_max) - throws DbException; -
Set the maximum number of active transactions that are supported by the -environment. This value bounds the size of backing shared memory regions. -Note that child transactions must be counted as active until their -ultimate parent commits or aborts. -
When there are more than the specified number of concurrent transactions, -calls to DbEnv.txn_begin will fail (until some active transactions -complete). If no value is specified, a default value of 20 is used. -
The DbEnv.set_tx_max interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_tx_max method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's maximum number of active transactions may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_tx_max", one or more whitespace characters, -and the number of transactions. Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_tx_recover.html b/bdb/docs/api_java/env_set_tx_recover.html deleted file mode 100644 index c3c71e9ba0f..00000000000 --- a/bdb/docs/api_java/env_set_tx_recover.html +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
-
-DbEnv.set_tx_recover- |
-
-
- |
-import com.sleepycat.db.*; --public interface DbTxnRecover -{ - public abstract int - tx_recover(DbEnv dbenv, Dbt log_rec, DbLsn lsn, int op); -} -public class DbEnv -{ - public void set_tx_recover(DbTxnRecover tx_recover) - throws DbException; - ... -} -
Set the application's method to be called during transaction abort -and recovery. This method must return 0 on success and either -errno or a value outside of the Berkeley DB error name space on -failure. It takes four arguments: -
The DbEnv.set_tx_recover interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_tx_recover method throws an exception that encapsulates a non-zero error value on -failure. -
Called after DbEnv.open was called. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_tx_timestamp.html b/bdb/docs/api_java/env_set_tx_timestamp.html deleted file mode 100644 index 93ae153a7e4..00000000000 --- a/bdb/docs/api_java/env_set_tx_timestamp.html +++ /dev/null @@ -1,64 +0,0 @@ - - - - -
-
-DbEnv.set_tx_timestamp- |
-
-
- |
-import com.sleepycat.db.*; --public void set_tx_timestamp(java.util.Date timestamp) - throws DbException; -
Recover to the time specified by timestamp rather than to the most -current possible date. -Note that only the seconds (not the milliseconds) of the timestamp -are used -
Once a database environment has been upgraded to a new version of Berkeley DB -involving a log format change (see Upgrading Berkeley DB installations, it is no longer possible to recover -to a specific time before that upgrade. -
The DbEnv.set_tx_timestamp interface may only be used to configure Berkeley DB before -the DbEnv.open interface is called. -
The DbEnv.set_tx_timestamp method throws an exception that encapsulates a non-zero error value on -failure. -
It is not possible to recover to the specified time using the -log files currently present in the environment. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_set_verbose.html b/bdb/docs/api_java/env_set_verbose.html deleted file mode 100644 index 8fbfb32ebac..00000000000 --- a/bdb/docs/api_java/env_set_verbose.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DbEnv.set_verbose- |
-
-
- |
-import com.sleepycat.db.*; --public int set_verbose(u_int32_t which, boolean onoff); -
The DbEnv.set_verbose method turns additional informational and -debugging messages in the Berkeley DB message output on and off. If -onoff is set to -true, -the additional messages are output. -
The which parameter must be set to one of the following values: -
The DbEnv.set_verbose interface may be used to configure Berkeley DB at any time -during the life of the application. -
The DbEnv.set_verbose method throws an exception that encapsulates a non-zero error value on -failure. -
The database environment's verbosity may also be set using the environment's -DB_CONFIG file. The syntax of the entry in that file is a -single line with the string "set_verbose", one or more whitespace characters, -and the interface which argument as a string, for example, -"set_verbose DB_VERB_CHKPOINT". Because the DB_CONFIG file is read when the database -environment is opened, it will silently overrule configuration done -before that time. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_strerror.html b/bdb/docs/api_java/env_strerror.html deleted file mode 100644 index e63e82e5f4c..00000000000 --- a/bdb/docs/api_java/env_strerror.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - -
-
-DbEnv.strerror- |
-
-
- |
-import com.sleepycat.db.*; --public static String strerror(int errcode); -
The DbEnv.strerror method returns an error message string corresponding -to the error number error. This interface is a superset of the -ANSI C X3.159-1989 (ANSI C) strerror(3) interface. If the error number -error is greater than or equal to 0, then the string returned by -the system interface strerror(3) is returned. If the error -number is less than 0, an error string appropriate to the corresponding -Berkeley DB library error is returned. See -Error returns to applications -for more information. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/env_version.html b/bdb/docs/api_java/env_version.html deleted file mode 100644 index ba0b1a034cf..00000000000 --- a/bdb/docs/api_java/env_version.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - -
-
-DbEnv.get_version_major- |
-
-
- |
-import com.sleepycat.db.*; --public static int get_version_major(); -public static int get_version_minor(); -public static int get_version_patch(); -public static String get_version_string(); -
These methods return version information about the underlying Berkeley DB -software. Berkeley DB is released with a major, minor and patch number, which -is returned by DbEnv.get_version_major, -DbEnv.get_version_minor and DbEnv.get_version_patch. -A verbose version of this information, suitable for display, is returned -by DbEnv.get_version_string. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/except_class.html b/bdb/docs/api_java/except_class.html deleted file mode 100644 index 885d161d556..00000000000 --- a/bdb/docs/api_java/except_class.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - -
-
-DbException- |
-
-
- |
-import com.sleepycat.db.*; --public class DbException extends Exception { ... } -
This manual page describes the DbException class and how it is used -by the various Berkeley DB classes. -
Most methods in the Berkeley DB classes throw an exception when an error occurs. -A DbException object contains an informational string and an errno. The -errno can be obtained using DbException.get_errno. Since DbException -inherits from the java.Exception, the string portion is available using -toString(). -
Some methods may return non-zero values without issuing an exception. -This occurs in situations that are not normally considered an error, but -when some informational status is returned. For example, Db.get -returns DB_NOTFOUND when a requested key does not appear in the database. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/get_errno.html b/bdb/docs/api_java/get_errno.html deleted file mode 100644 index 5d3850d1f84..00000000000 --- a/bdb/docs/api_java/get_errno.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - -
-
-DbException.get_errno- |
-
-
- |
-import com.sleepycat.db.*; --public int get_errno(); -
Most methods in the Db classes throw an exception when an error occurs. -A DbException object contains an informational string and an errno. -The errno can be obtained using DbException.get_errno. -Since DbException inherits from the java.Exception, the string -portion is available using toString(). -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/java_index.html b/bdb/docs/api_java/java_index.html deleted file mode 100644 index c36227edeba..00000000000 --- a/bdb/docs/api_java/java_index.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - -
-| Class | Method | Description |
|---|---|---|
| DbEnv | Berkeley DB Environment Class | |
| DbEnv.close | Close an environment | |
| DbEnv.open | Open an environment | |
| DbEnv.remove | Remove an environment | |
| DbEnv.set_cachesize | Set the environment cache size | |
| DbEnv.set_data_dir | Set the environment data directory | |
| DbEnv.set_errcall | Set error message callback | |
| DbEnv.set_error_stream | Set error message output stream | |
| DbEnv.set_errpfx | Set error message prefix | |
| DbEnv.set_feedback | Set feedback callback | |
| DbEnv.set_flags | Environment configuration | |
| DbEnv.set_lg_bsize | Set log buffer size | |
| DbEnv.set_lg_dir | Set the environment logging directory | |
| DbEnv.set_lg_max | Set log file size | |
| DbEnv.set_lk_conflicts | Set lock conflicts matrix | |
| DbEnv.set_lk_detect | Set automatic deadlock detection | |
| DbEnv.set_lk_max | Set maximum number of locks (Deprecated) | |
| DbEnv.set_lk_max_locks | Set maximum number of locks | |
| DbEnv.set_lk_max_lockers | Set maximum number of lockers | |
| DbEnv.set_lk_max_objects | Set maximum number of lock objects | |
| DbEnv.set_mp_mmapsize | Set maximum mapped-in database file size | |
| DbEnv.set_mutexlocks | Turn off mutual exclusion locking | |
| DbEnv.set_pageyield | Yield the processor on each page access | |
| DbEnv.set_panicstate | Reset panic state | |
| DbEnv.set_recovery_init | Set recovery initialization callback | |
| DbEnv.set_region_init | Fault in shared regions on initial access | |
| DbEnv.set_server | Establish server connection | |
| DbEnv.set_shm_key | Set system memory shared segment ID | |
| DbEnv.set_tas_spins | Set the number of test-and-set spins | |
| DbEnv.set_tmp_dir | Set the environment temporary file directory | |
| DbEnv.set_tx_max | Set maximum number of transactions | |
| DbEnv.set_tx_recover | Set transaction abort recover function | |
| DbEnv.set_tx_timestamp | Set recovery timestamp | |
| DbEnv.set_verbose | Set verbose messages | |
| DbEnv.strerror | Error strings | |
| DbEnv.lock_detect | Perform deadlock detection | |
| DbEnv.lock_get | Acquire a lock | |
| DbEnv.lock_id | Acquire a locker ID | |
| DbEnv.lock_stat | Return lock subsystem statistics | |
| DbEnv.log_archive | List log and database files | |
| DbEnv.log_compare | Compare two Log Sequence Numbers | |
| DbEnv.log_file | Map Log Sequence Numbers to log files | |
| DbEnv.log_flush | Flush log records | |
| DbEnv.log_get | Get a log record | |
| DbEnv.log_put | Write a log record | |
| DbEnv.log_register | Register a file name with the log manager | |
| DbEnv.log_stat | Return log subsystem statistics | |
| DbEnv.log_unregister | Unregister a file name with the log manager | |
| DbEnv.memp_fstat | Return buffer pool statistics. | |
| DbEnv.memp_stat | Return buffer pool statistics | |
| DbEnv.memp_trickle | Trickle flush pages from a buffer pool | |
| DbEnv.txn_begin | Begin a transaction | |
| DbEnv.txn_checkpoint | Checkpoint the transaction subsystem | |
| DbEnv.txn_stat | Return transaction subsystem statistics | |
| DbEnv.version | Return version information | |
| Db | Berkeley DB Access Method Class | |
| Db.close | Close a database | |
| Db.cursor | Open a cursor into a database | |
| Db.del | Delete items from a database | |
| Db.fd | Return a file descriptor from a database | |
| Db.get | Get items from a database | |
| Db.get_byteswapped | Return if the underlying database is in host order | |
| Db.get_type | Return the database type | |
| Db.join | Perform a database join on cursors | |
| Db.key_range | Return estimate of key location | |
| Db.open | Open a database | |
| Db.put | Store items into a database | |
| Db.remove | Remove a database | |
| Db.rename | Rename a database | |
| Db.set_append_recno | Set record append callback | |
| Db.set_bt_compare | Set a Btree comparison function | |
| Db.set_bt_minkey | Set the minimum number of keys per Btree page | |
| Db.set_bt_prefix | Set a Btree prefix comparison function | |
| Db.set_cachesize | Set the database cache size | |
| Db.set_dup_compare | Set a duplicate comparison function | |
| Db.set_errcall | Set error message callback | |
| Db.set_errpfx | Set error message prefix | |
| Db.set_feedback | Set feedback callback | |
| Db.set_flags | General database configuration | |
| Db.set_h_ffactor | Set the Hash table density | |
| Db.set_h_hash | Set a hashing function | |
| Db.set_h_nelem | Set the Hash table size | |
| Db.set_lorder | Set the database byte order | |
| Db.set_pagesize | Set the underlying database page size | |
| Db.set_q_extentsize | Set Queue database extent size | |
| Db.set_re_delim | Set the variable-length record delimiter | |
| Db.set_re_len | Set the fixed-length record length | |
| Db.set_re_pad | Set the fixed-length record pad byte | |
| Db.set_re_source | Set the backing Recno text file | |
| Db.stat | Return database statistics | |
| Db.sync | Flush a database to stable storage | |
| Db.upgrade | Upgrade a database | |
| Db.verify | Verify/upgrade a database | |
| Dbc | Berkeley DB Cursor Class | |
| Dbc.close | Close a cursor | |
| Dbc.count | Return count of duplicates | |
| Dbc.del | Delete by cursor | |
| Dbc.dup | Duplicate a cursor | |
| Dbc.get | Retrieve by cursor | |
| Dbc.put | Store by cursor | |
| Dbt | Key/Data Encoding Class | |
| DbLock | Lock Class | |
| DbLock.put | Release a lock | |
| DbLsn | Log Sequence Number Class | |
| DbTxn | Transaction Class | |
| DbTxn.abort | Abort a transaction | |
| DbTxn.commit | Commit a transaction | |
| DbTxn.id | Return a transaction ID | |
| DbTxn.prepare | Prepare a transaction for commit | |
| DbException | Exception Class for Berkeley DB Activity | |
| DbException.get_errno | Get the error value | |
| DbDeadlockException | Exception Class for deadlocks | |
| DbMemoryException | Exception Class for insufficient memory | |
| DbRunRecoveryException | Exception Class for failures requiring recovery |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/java_pindex.html b/bdb/docs/api_java/java_pindex.html deleted file mode 100644 index 5ac50e4791b..00000000000 --- a/bdb/docs/api_java/java_pindex.html +++ /dev/null @@ -1,478 +0,0 @@ - -
-| configuring Berkeley DB | 1.85 API compatibility |
| building a utility to dump Berkeley DB | 1.85 databases |
| Upgrading to release | 2.0 |
| Upgrading to release | 3.0 |
| Upgrading to release | 3.1 |
| Upgrading to release | 3.2 |
| selecting an | access method |
| access methods | |
| AIX | |
| programmatic | APIs |
| utility to | archive log files |
| berkeley_db_svc | |
| building for UNIX | |
| building for UNIX FAQ | |
| building for VxWorks | |
| building for VxWorks FAQ | |
| building for Win32 | |
| building for Windows FAQ | |
| selecting a | byte order |
| byte ordering | |
| configuring the | C++ API |
| flushing the database | cache |
| selecting a | cache size |
| catastrophic recovery | |
| Patches, Updates and | Change logs |
| utility to take | checkpoints |
| closing a cursor | |
| closing a database | |
| specifying a Btree | comparison function |
| changing | compile or load options |
| Concurrent Data Store | |
| configuring Berkeley DB for UNIX systems | |
| recovering | corrupted databases |
| counting data items for a key | |
| closing a | cursor |
| deleting records with a | cursor |
| duplicating a | cursor |
| retrieving records with a | cursor |
| storing records with a | cursor |
| cursor stability | |
| database | cursors |
| Dbt | data |
| utility to upgrade | database files |
| utility to verify | database files |
| Db | |
| db_archive | |
| Dbc | |
| Dbc.close | |
| Dbc.count | |
| Dbc.del | |
| Dbc.dup | |
| Dbc.get | |
| db_checkpoint | |
| Db.close | |
| File naming | DB_CONFIG |
| Dbc.put | |
| Db.cursor | |
| Dbc.put | Db.DB_AFTER |
| Db.verify | Db.DB_AGGRESSIVE |
| Db.put | Db.DB_APPEND |
| DbEnv.log_archive | Db.DB_ARCH_ABS |
| DbEnv.log_archive | Db.DB_ARCH_DATA |
| DbEnv.log_archive | Db.DB_ARCH_LOG |
| Dbc.put | Db.DB_BEFORE |
| Db.stat | Db.DB_CACHED_COUNTS |
| DbEnv.set_flags | Db.DB_CDB_ALLDB |
| DbEnv.log_get | Db.DB_CHECKPOINT |
| DbEnv.log_put | Db.DB_CHECKPOINT |
| DbEnv | Db.DB_CLIENT |
| Db.get | Db.DB_CONSUME |
| Db.get | Db.DB_CONSUME_WAIT |
| Db.open | Db.DB_CREATE |
| DbEnv.open | Db.DB_CREATE |
| DbEnv.log_put | Db.DB_CURLSN |
| Dbc.get | Db.DB_CURRENT |
| Dbc.put | Db.DB_CURRENT |
| DbEnv.log_get | Db.DB_CURRENT |
| Dbt | Db.DB_DBT_MALLOC |
| Dbt | Db.DB_DBT_PARTIAL |
| Dbt | Db.DB_DBT_REALLOC |
| Dbt | Db.DB_DBT_USERMEM |
| Db.set_flags | Db.DB_DUP |
| Db.set_flags | Db.DB_DUPSORT |
| Db.upgrade | Db.DB_DUPSORT |
| Db.open | Db.DB_EXCL |
| Dbc.get | Db.DB_FIRST |
| DbEnv.log_get | Db.DB_FIRST |
| DbEnv.log_put | Db.DB_FLUSH |
| DbEnv.remove | Db.DB_FORCE |
| DbEnv.txn_checkpoint | Db.DB_FORCE |
| Db.get | Db.DB_GET_BOTH |
| Dbc.get | Db.DB_GET_BOTH |
| Dbc.get | Db.DB_GET_RECNO |
| DbEnv.open | Db.DB_INIT_CDB |
| DbEnv.open | Db.DB_INIT_LOCK |
| DbEnv.open | Db.DB_INIT_LOG |
| DbEnv.open | Db.DB_INIT_MPOOL |
| DbEnv.open | Db.DB_INIT_TXN |
| DbEnv.open | Db.DB_JOINENV |
| Db.join | Db.DB_JOIN_ITEM |
| Dbc.get | Db.DB_JOIN_ITEM |
| Db.join | Db.DB_JOIN_NOSORT |
| Dbc.put | Db.DB_KEYFIRST |
| Dbc.put | Db.DB_KEYLAST |
| Dbc.get | Db.DB_LAST |
| DbEnv.log_get | Db.DB_LAST |
| DbEnv.lock_detect | Db.DB_LOCK_CONFLICT |
| DbEnv.open | Db.DB_LOCKDOWN |
| DbEnv.lock_get | Db.DB_LOCK_NOTGRANTED |
| DbEnv.lock_get | Db.DB_LOCK_NOWAIT |
| Dbc.get | Db.DB_NEXT |
| DbEnv.log_get | Db.DB_NEXT |
| Dbc.get | Db.DB_NEXT_DUP |
| Dbc.get | Db.DB_NEXT_NODUP |
| Db.put | Db.DB_NODUPDATA |
| Dbc.put | Db.DB_NODUPDATA |
| Db.open | Db.DB_NOMMAP |
| DbEnv.set_flags | Db.DB_NOMMAP |
| Db.verify | Db.DB_NOORDERCHK |
| Db.put | Db.DB_NOOVERWRITE |
| Db.close | Db.DB_NOSYNC |
| Db.open | Db.DB_OLD_VERSION |
| Db.upgrade | Db.DB_OLD_VERSION |
| Db.verify | Db.DB_ORDERCHKONLY |
| Dbc.dup | Db.DB_POSITION |
| Dbc.get | Db.DB_PREV |
| DbEnv.log_get | Db.DB_PREV |
| Dbc.get | Db.DB_PREV_NODUP |
| DbEnv.open | Db.DB_PRIVATE |
| Db.open | Db.DB_RDONLY |
| Db.set_flags | Db.DB_RECNUM |
| Db.stat | Db.DB_RECORDCOUNT |
| DbEnv.open | Db.DB_RECOVER |
| DbEnv.set_feedback | Db.DB_RECOVER |
| DbEnv.open | Db.DB_RECOVER_FATAL |
| Db.set_flags | Db.DB_RENUMBER |
| Db.set_flags | Db.DB_REVSPLITOFF |
| Db.get | Db.DB_RMW |
| Db.join | Db.DB_RMW |
| Dbc.get | Db.DB_RMW |
| Db.verify | Db.DB_SALVAGE |
| Dbc.get | Db.DB_SET |
| DbEnv.log_get | Db.DB_SET |
| Dbc.get | Db.DB_SET_RANGE |
| Db.get | Db.DB_SET_RECNO |
| Dbc.get | Db.DB_SET_RECNO |
| Db.set_flags | Db.DB_SNAPSHOT |
| DbEnv.open | Db.DB_SYSTEM_MEM |
| Db.open | Db.DB_THREAD |
| DbEnv.open | Db.DB_THREAD |
| Db.open | Db.DB_TRUNCATE |
| DbEnv.set_tx_recover | Db.DB_TXN_ABORT |
| DbEnv.set_tx_recover | Db.DB_TXN_BACKWARD_ROLL |
| DbEnv.set_tx_recover | Db.DB_TXN_FORWARD_ROLL |
| DbEnv.set_flags | Db.DB_TXN_NOSYNC |
| DbEnv.txn_begin | Db.DB_TXN_NOSYNC |
| DbTxn.commit | Db.DB_TXN_NOSYNC |
| DbEnv.txn_begin | Db.DB_TXN_NOWAIT |
| DbEnv.txn_begin | Db.DB_TXN_SYNC |
| DbTxn.commit | Db.DB_TXN_SYNC |
| Db.set_feedback | Db.DB_UPGRADE |
| DbEnv.open | Db.DB_USE_ENVIRON |
| DbEnv.remove | Db.DB_USE_ENVIRON |
| DbEnv.open | Db.DB_USE_ENVIRON_ROOT |
| DbEnv.remove | Db.DB_USE_ENVIRON_ROOT |
| DbEnv.set_verbose | Db.DB_VERB_CHKPOINT |
| DbEnv.set_verbose | Db.DB_VERB_DEADLOCK |
| DbEnv.set_verbose | Db.DB_VERB_RECOVERY |
| DbEnv.set_verbose | Db.DB_VERB_WAITSFOR |
| Db.set_feedback | Db.DB_VERIFY |
| Db.cursor | Db.DB_WRITECURSOR |
| Db | Db.DB_XA_CREATE |
| db_deadlock | |
| DbDeadlockException | |
| Db.del | |
| db_dump | |
| DbEnv | |
| DbEnv.close | |
| DbEnv.get_version_major | |
| DbEnv.lock_detect | |
| DbEnv.lock_get | |
| DbEnv.lock_id | |
| DbEnv.lock_stat | |
| DbEnv.lock_vec | |
| DbEnv.log_archive | |
| DbEnv.log_compare | |
| DbEnv.log_file | |
| DbEnv.log_flush | |
| DbEnv.log_get | |
| DbEnv.log_put | |
| DbEnv.log_register | |
| DbEnv.log_stat | |
| DbEnv.log_unregister | |
| DbEnv.memp_register | |
| DbEnv.memp_stat | |
| DbEnv.memp_sync | |
| DbEnv.memp_trickle | |
| DbEnv.open | |
| DbEnv.remove | |
| DbEnv.set_cachesize | |
| DbEnv.set_data_dir | |
| DbEnv.set_errcall | |
| DbEnv.set_error_stream | |
| DbEnv.set_errpfx | |
| DbEnv.set_feedback | |
| DbEnv.set_flags | |
| DbEnv.set_lg_bsize | |
| DbEnv.set_lg_dir | |
| DbEnv.set_lg_max | |
| DbEnv.set_lk_conflicts | |
| DbEnv.set_lk_detect | |
| DbEnv.set_lk_max | |
| DbEnv.set_lk_max_lockers | |
| DbEnv.set_lk_max_locks | |
| DbEnv.set_lk_max_objects | |
| DbEnv.set_mp_mmapsize | |
| DbEnv.set_mutexlocks | |
| DbEnv.set_pageyield | |
| DbEnv.set_panicstate | |
| DbEnv.set_recovery_init | |
| DbEnv.set_region_init | |
| DbEnv.set_server | |
| DbEnv.set_shm_key | |
| DbEnv.set_tas_spins | |
| DbEnv.set_tmp_dir | |
| DbEnv.set_tx_max | |
| DbEnv.set_tx_recover | |
| DbEnv.set_tx_timestamp | |
| DbEnv.set_verbose | |
| DbEnv.strerror | |
| DbEnv.txn_begin | |
| DbEnv.txn_checkpoint | |
| DbEnv.txn_stat | |
| DbException | |
| DbException.get_errno | |
| Db.fd | |
| Db.get | |
| Db.get_byteswapped | |
| Db.get_type | |
| File naming | DB_HOME |
| File naming | db_home |
| Db.close | DB_INCOMPLETE |
| Db.join | |
| Error returns to applications | DB_KEYEMPTY |
| Db.key_range | |
| db_load | |
| DbLock | |
| Error returns to applications | DB_LOCK_DEADLOCK |
| DbEnv.set_lk_detect | DB_LOCK_DEFAULT |
| Error returns to applications | DB_LOCK_NOTGRANTED |
| DbEnv.set_lk_detect | DB_LOCK_OLDEST |
| DbLock.put | |
| DbEnv.set_lk_detect | DB_LOCK_RANDOM |
| DbEnv.set_lk_detect | DB_LOCK_YOUNGEST |
| DbLsn | |
| DbMemoryException | |
| DbMpoolFile.close | |
| DbMpoolFile.get | |
| DbMpoolFile.open | |
| DbMpoolFile.put | |
| DbMpoolFile.set | |
| DbMpoolFile.sync | |
| DbEnv.set_server | DB_NOSERVER |
| DbEnv.set_server | DB_NOSERVER_ID |
| Error returns to applications | DB_NOTFOUND |
| Db.open | |
| db_printlog | |
| Db.put | |
| db_recover | |
| Db.remove | |
| Db.rename | |
| Error returns to applications | DB_RUNRECOVERY |
| DbRunRecoveryException | |
| Db.set_append_recno | |
| Db.set_bt_compare | |
| Db.set_bt_minkey | |
| Db.set_bt_prefix | |
| Db.set_cachesize | |
| Db.set_dup_compare | |
| Db.set_errcall | |
| Db.set_errpfx | |
| Db.set_feedback | |
| Db.set_flags | |
| Db.set_h_ffactor | |
| Db.set_h_hash | |
| Db.set_h_nelem | |
| Db.set_lorder | |
| Db.set_pagesize | |
| Db.set_q_extentsize | |
| Db.set_re_delim | |
| Db.set_re_len | |
| Db.set_re_pad | |
| Db.set_re_source | |
| Db.stat | |
| db_stat | |
| Db.sync | |
| Dbt | |
| DbTxn | |
| DbTxn.abort | |
| DbTxn.commit | |
| DbTxn.id | |
| DbTxn.prepare | |
| Db.upgrade | |
| db_upgrade | |
| Db.verify | |
| db_verify | |
| deadlocks | |
| utility to detect | deadlocks |
| debugging applications | |
| deleting records | |
| deleting records with a cursor | |
| Configuring Berkeley DB | --disable-bigfile |
| disk space requirements | |
| utility to | dump databases as text files |
| duplicate data items | |
| duplicating a cursor | |
| configuring | dynamic shared libraries |
| Configuring Berkeley DB | --enable-compat185 |
| Configuring Berkeley DB | --enable-cxx |
| Configuring Berkeley DB | --enable-debug |
| Configuring Berkeley DB | --enable-debug_rop |
| Configuring Berkeley DB | --enable-debug_wop |
| Configuring Berkeley DB | --enable-diagnostic |
| Configuring Berkeley DB | --enable-dump185 |
| Configuring Berkeley DB | --enable-dynamic |
| Configuring Berkeley DB | --enable-java |
| Configuring Berkeley DB | --enable-posixmutexes |
| Configuring Berkeley DB | --enable-rpc |
| Configuring Berkeley DB | --enable-shared |
| Configuring Berkeley DB | --enable-tcl |
| Configuring Berkeley DB | --enable-test |
| Configuring Berkeley DB | --enable-uimutexes |
| Configuring Berkeley DB | --enable-umrw |
| byte | endian |
| database | environment |
| environment variables | |
| error handling | |
| error name space | |
| error returns | |
| /etc/magic | |
| selecting a Queue | extent size |
| Java | FAQ |
| Tcl | FAQ |
| configuring without large | file support |
| file utility | |
| recovery and | filesystem operations |
| remote | filesystems |
| page | fill factor |
| FreeBSD | |
| Berkeley DB | free-threaded handles |
| specifying a database | hash |
| hash table size | |
| HP-UX | |
| installing Berkeley DB for UNIX systems | |
| interface compatibility | |
| IRIX | |
| configuring the | Java API |
| Java compatibility | |
| Java configuration | |
| Java FAQ | |
| logical | join |
| key/data pairs | |
| database | limits |
| Linux | |
| changing compile or | load options |
| utility to | load text files into databases |
| standard | lock modes |
| page-level | locking |
| two-phase | locking |
| locking and non-Berkeley DB applications | |
| locking configuration | |
| locking conventions | |
| Berkeley DB Concurrent Data Store | locking conventions |
| locking introduction | |
| sizing the | locking subsystem |
| locking without transactions | |
| log file limits | |
| log file removal | |
| utility to display | log files as text |
| logging configuration | |
| logging introduction | |
| memory pool configuration | |
| Berkeley DB library | name spaces |
| file | naming |
| retrieving Btree records by | number |
| opening a database | |
| OSF/1 | |
| selecting a | page size |
| partial record storage and retrieval | |
| Patches, Updates and Change logs | |
| Perl | |
| Sleepycat Software's Berkeley DB | products |
| QNX | |
| logical | record number format |
| logical | record numbers |
| managing | record-based databases |
| logically renumbering | records |
| utility to | recover database environments |
| Berkeley DB | recoverability |
| retrieving records | |
| retrieving records with a cursor | |
| RPC client | |
| configuring a | RPC client/server |
| utility to support | RPC client/server |
| RPC server | |
| database | salvage |
| SCO | |
| Berkeley DB handle | scope |
| security | |
| Sendmail | |
| configuring | shared libraries |
| shared libraries | |
| application | signal handling |
| Sleepycat Software | |
| Solaris | |
| source code layout | |
| cursor | stability |
| database | statistics |
| utility to display database and environment | statistics |
| storing records | |
| storing records with a cursor | |
| SunOS | |
| loading Berkeley DB with | Tcl |
| using Berkeley DB with | Tcl |
| configuring the | Tcl API |
| Tcl API programming notes | |
| Tcl FAQ | |
| configuring the | test suite |
| running the | test suite |
| running the | test suite under UNIX |
| running the | test suite under Windows |
| text backing files | |
| loading | text into databases |
| dumping/loading | text to/from databases |
| building | threaded applications |
| transaction configuration | |
| transaction limits | |
| administering | transaction protected applications |
| archival in | transaction protected applications |
| checkpoints in | transaction protected applications |
| deadlock detection in | transaction protected applications |
| recovery in | transaction protected applications |
| transaction throughput | |
| Transactional Data Store | |
| Berkeley DB and | transactions |
| nested | transactions |
| configuring Berkeley DB with the | Tuxedo System |
| Ultrix | |
| building for | UNIX FAQ |
| configuring Berkeley DB for | UNIX systems |
| Patches, | Updates and Change logs |
| utility to | upgrade database files |
| upgrading databases | |
| utilities | |
| database | verification |
| utility to | verify database files |
| building for | VxWorks FAQ |
| VxWorks notes | |
| running the test suite under | Windows |
| building for | Windows FAQ |
| Windows notes | |
| Configuring Berkeley DB | --with-tcl=DIR |
| XA Resource Manager |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_class.html b/bdb/docs/api_java/lock_class.html deleted file mode 100644 index 6705e95bdfd..00000000000 --- a/bdb/docs/api_java/lock_class.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - -
-
-DbLock- |
-
-
- |
-import com.sleepycat.db.*; --public class DbLock extends Object { ... } -
The DbEnv lock methods and the DbLock class are used -to provide general-purpose locking. While designed to work with the -other Db classes, they are also useful for more general locking -purposes. Locks can be shared between processes. -
In most cases, when multiple threads or processes are using locking, the -deadlock detector, db_deadlock should be run. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_detect.html b/bdb/docs/api_java/lock_detect.html deleted file mode 100644 index 6f453ddb8e6..00000000000 --- a/bdb/docs/api_java/lock_detect.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - -
-
-DbEnv.lock_detect- |
-
-
- |
-import com.sleepycat.db.*; --public int lock_detect(int flags, int atype) - throws DbException; -
The DbEnv.lock_detect method runs one iteration of the deadlock detector. -The deadlock detector traverses the lock table, and for each deadlock -it finds, marks one of the participating transactions for abort. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The atype parameter specifies which transaction to abort in the -case of deadlock. It must be set to one of possible arguments listed for -the DbEnv.set_lk_detect interface. -
The DbEnv.lock_detect method returns the number of transactions aborted. -
The DbEnv.lock_detect method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.lock_detect method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.lock_detect method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_get.html b/bdb/docs/api_java/lock_get.html deleted file mode 100644 index 42604bc46d9..00000000000 --- a/bdb/docs/api_java/lock_get.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-DbEnv.lock_get- |
-
-
- |
-import com.sleepycat.db.*; --public DbLock lock_get(int locker, - int flags, Dbt obj, int lock_mode) - throws DbException; -
The DbEnv.lock_get method acquires a lock from the lock table, returning -information about it in -a DbLock object. -
The locker argument specified to DbEnv.lock_get is an unsigned -32-bit integer quantity. It represents the entity requesting or releasing -the lock. -
The flags value must be set to 0 or the following value: -
The obj argument is an untyped byte string that specifies the -object to be locked or released. -
The mode argument is an index into the environment's lock conflict -array. See DbEnv.set_lk_conflicts and -Standard Lock Modes -for a description of that array. -
The DbEnv.lock_get method may -throw an exception encapsulating -one of the following values: -
Otherwise, the DbEnv.lock_get method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.lock_get method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
If the operation was selected to resolve a deadlock, the -DbEnv.lock_get method will fail and -throw a DbDeadlockException exception. -
The DbEnv.lock_get method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.lock_get method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_id.html b/bdb/docs/api_java/lock_id.html deleted file mode 100644 index 2fa59317fe9..00000000000 --- a/bdb/docs/api_java/lock_id.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - -
-
-DbEnv.lock_id- |
-
-
- |
-import com.sleepycat.db.*; --public int lock_id() - throws DbException; -
The DbEnv.lock_id method -returns a locker ID, which is guaranteed to be unique in the specified lock -table. -
The DbEnv.lock_id method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.lock_id method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.lock_id method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_put.html b/bdb/docs/api_java/lock_put.html deleted file mode 100644 index fe4eacc28af..00000000000 --- a/bdb/docs/api_java/lock_put.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - -
-
-DbLock.put- |
-
-
- |
-import com.sleepycat.db.*; --public native void put(DbEnv env) - throws DbException; -
The DbLock.put method releases lock from the lock table. -
The DbLock.put method throws an exception that encapsulates a non-zero error value on -failure. -
The DbLock.put method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbLock.put method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbLock.put method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_stat.html b/bdb/docs/api_java/lock_stat.html deleted file mode 100644 index 00c3703f528..00000000000 --- a/bdb/docs/api_java/lock_stat.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - -
-
-DbEnv.lock_stat- |
-
-
- |
-import com.sleepycat.db.*; --public DbLockStat lock_stat() - throws DbException; -
The DbEnv.lock_stat method -creates a DbLockStat object encapsulating a statistical structure. -The lock region statistics are stored in a DbLockStat object. -The following data fields are available from the DbLockStat object: -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The lock region statistics are stored in a structure of type -DB_LOCK_STAT. The following DB_LOCK_STAT fields will be filled in: -
The DbEnv.lock_stat method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.lock_stat method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.lock_stat method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lock_vec.html b/bdb/docs/api_java/lock_vec.html deleted file mode 100644 index 233e036a370..00000000000 --- a/bdb/docs/api_java/lock_vec.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbEnv.lock_vec- |
-
-
- |
-import com.sleepycat.db.*; -
A DbEnv.lock_vec method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_archive.html b/bdb/docs/api_java/log_archive.html deleted file mode 100644 index a842286585d..00000000000 --- a/bdb/docs/api_java/log_archive.html +++ /dev/null @@ -1,92 +0,0 @@ - - - - -
-
-DbEnv.log_archive- |
-
-
- |
-import com.sleepycat.db.*; --public String[] log_archive(int flags) - throws DbException; -
The DbEnv.log_archive method -returns an array of log or database file names. -
By default, DbEnv.log_archive returns the names of all of the log files -that are no longer in use (e.g., no longer involved in active transactions), -and that may safely be archived for catastrophic recovery and then removed -from the system. If there were no file names to return, the memory location -referenced by listp will be set to null. -
The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more -of the following values. -
The Db.DB_ARCH_DATA and Db.DB_ARCH_LOG flags are mutually -exclusive. -
See the db_archive manual page for more information on database -archival procedures. -
The DbEnv.log_archive method throws an exception that encapsulates a non-zero error value on -failure. -
In a threaded application (i.e., one where the environment was created -with the DB_THREAD flag specified), calling DbEnv.log_archive with the -DB_ARCH_DATA flag will fail, returning EINVAL. To work around this -problem, re-open the log explicitly without specifying DB_THREAD. This -restriction is expected to be removed in a future version of Berkeley DB. -
The DbEnv.log_archive method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The log was corrupted. -
The DbEnv.log_archive method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_archive method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_compare.html b/bdb/docs/api_java/log_compare.html deleted file mode 100644 index aba583203e1..00000000000 --- a/bdb/docs/api_java/log_compare.html +++ /dev/null @@ -1,52 +0,0 @@ - - - - -
-
-DbEnv.log_compare- |
-
-
- |
-import com.sleepycat.db.*; --public static int log_compare(DbLsn lsn0, DbLsn lsn1); -
The DbEnv.log_compare method allows the caller to compare two -DbLsn objects, -returning 0 if they are equal, 1 if lsn0 is greater than -lsn1, and -1 if lsn0 is less than lsn1. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_file.html b/bdb/docs/api_java/log_file.html deleted file mode 100644 index e85fa46df14..00000000000 --- a/bdb/docs/api_java/log_file.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - -
-
-DbEnv.log_file- |
-
-
- |
-import com.sleepycat.db.*; --public String log_file(DbLsn lsn) - throws DbException; -
The DbEnv.log_file method maps -DbLsn objects -to file names, -returning the name of the file containing the record named by lsn. -
The len argument is the length of the namep buffer in bytes. -If namep is too short to hold the file name, DbEnv.log_file will -return ENOMEM. -(Log file names are normally quite short, on the order of 10 characters.) -
This mapping of -DbLsn objects -to files is needed for database administration. For example, a -transaction manager typically records the earliest -DbLsn -needed for restart, and the database administrator may want to archive -log files to tape when they contain only -DbLsn -entries before the earliest one needed for restart. -
The DbEnv.log_file method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_file method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.log_file method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_file method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_flush.html b/bdb/docs/api_java/log_flush.html deleted file mode 100644 index 4396d21f7cb..00000000000 --- a/bdb/docs/api_java/log_flush.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - -
-
-DbEnv.log_flush- |
-
-
- |
-import com.sleepycat.db.*; --public void log_flush(DbLsn lsn) - throws DbException; -
The DbEnv.log_flush method guarantees that all log records whose -DbLsn values -are less than or equal to the lsn argument have been -written to disk. If lsn is null, all records in the -log are flushed. -
The DbEnv.log_flush method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_flush method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.log_flush method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_flush method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_get.html b/bdb/docs/api_java/log_get.html deleted file mode 100644 index 94eed013408..00000000000 --- a/bdb/docs/api_java/log_get.html +++ /dev/null @@ -1,117 +0,0 @@ - - - - -
-
-DbEnv.log_get- |
-
-
- |
-import com.sleepycat.db.*; --public void log_get(DbLsn lsn, Dbt data, int flags) - throws DbException; -
The DbEnv.log_get method implements a cursor inside of the log, -retrieving records from the log according to the lsn and -flags arguments. -
The data field of the data structure is set to the record -retrieved and the size field indicates the number of bytes in the record. -See Dbt for a description of other fields in the data -structure. When multiple threads are using the returned log handle -concurrently, one of the Db.DB_DBT_MALLOC, Db.DB_DBT_REALLOC or -Db.DB_DBT_USERMEM flags must be specified for any Dbt used -for data retrieval. -
The flags argument must be set to exactly one of the following values: -
If the log is empty, the DbEnv.log_get method will return Db.DB_NOTFOUND. -
If the log is empty, the DbEnv.log_get method will return Db.DB_NOTFOUND. -
If the log is empty, the DbEnv.log_get method will return Db.DB_NOTFOUND. -
If the pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, DbEnv.log_get will return the first record in the log. -If the last log record has already been returned or the log is empty, the -DbEnv.log_get method will return Db.DB_NOTFOUND. -
If the log was opened with the DB_THREAD flag set, calls to -DbEnv.log_get with the DB_NEXT flag set will return EINVAL. -
If the pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, -DbEnv.log_get will return the last record in the log. -If the first log record has already been returned or the log is empty, the -DbEnv.log_get method will return Db.DB_NOTFOUND. -
If the log was opened with the DB_THREAD flag set, calls to -DbEnv.log_get with the DB_PREV flag set will return EINVAL. -
If the log pointer has not been initialized via DB_FIRST, DB_LAST, DB_SET, -DB_NEXT, or DB_PREV, or if the log was opened with the DB_THREAD flag set, -DbEnv.log_get will return EINVAL. -
Otherwise, the DbEnv.log_get method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_get method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DB_FIRST flag was specified and no log files were found. -
The DbEnv.log_get method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_get method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_put.html b/bdb/docs/api_java/log_put.html deleted file mode 100644 index 03749f20d66..00000000000 --- a/bdb/docs/api_java/log_put.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - -
-
-DbEnv.log_put- |
-
-
- |
-import com.sleepycat.db.*; --public void log_put(DbLsn lsn, Dbt data, int flags) - throws DbException; -
The DbEnv.log_put method appends records to the log. The DbLsn of -the put record is returned in the lsn argument. The flags -argument may be set to one of the following values: -
The caller is responsible for providing any necessary structure to -data. (For example, in a write-ahead logging protocol, the -application must understand what part of data is an operation -code, what part is redo information, and what part is undo information. -In addition, most transaction managers will store in data the -DbLsn of the previous log record for the same transaction, to -support chaining back through the transaction's log records during -undo.) -
The DbEnv.log_put method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_flush method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The record to be logged is larger than the maximum log record. -
The DbEnv.log_put method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_put method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_register.html b/bdb/docs/api_java/log_register.html deleted file mode 100644 index 7d4833c3c1a..00000000000 --- a/bdb/docs/api_java/log_register.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - -
-
-DbEnv.log_register- |
-
-
- |
-import com.sleepycat.db.*; --public int log_register(Db dbp, String name) - throws DbException; -
The DbEnv.log_register method registers a file name with the specified Berkeley DB -environment's log manager. The log manager records all file name mappings -at each checkpoint so that a recovery process can identify the file to -which a record in the log refers. -
The dbp argument should be a reference to the Db object being -registered. The name argument should be a file name appropriate -for opening the file in the environment, during recovery. -
The DbEnv.log_register method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_register method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.log_register method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_register method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_stat.html b/bdb/docs/api_java/log_stat.html deleted file mode 100644 index 4c51f1095a3..00000000000 --- a/bdb/docs/api_java/log_stat.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - -
-
-DbEnv.log_stat- |
-
-
- |
-import com.sleepycat.db.*; --public DbLogStat log_stat() - throws DbException; -
The DbEnv.log_stat method -creates a DbLogStat object encapsulating a statistical structure. -The log region statistics are stored in a DbLogStat object. -The following data fields are available from the DbLogStat object: -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The log region statistics are stored in a structure of type DB_LOG_STAT. -The following DB_LOG_STAT fields will be filled in: -
The DbEnv.log_stat method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_stat method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_stat method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/log_unregister.html b/bdb/docs/api_java/log_unregister.html deleted file mode 100644 index c79c324ee83..00000000000 --- a/bdb/docs/api_java/log_unregister.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
-DbEnv.log_unregister- |
-
-
- |
-import com.sleepycat.db.*; --public void log_unregister(Db dbp) - throws DbException; -
The DbEnv.log_unregister method function unregisters the file represented by -the dbp parameter from the Berkeley DB environment's log manager. -
The DbEnv.log_unregister method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.log_unregister method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.log_unregister method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.log_unregister method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/lsn_class.html b/bdb/docs/api_java/lsn_class.html deleted file mode 100644 index 891ba8d0cea..00000000000 --- a/bdb/docs/api_java/lsn_class.html +++ /dev/null @@ -1,37 +0,0 @@ - - - - -
-
-DbLsn- |
-
-
- |
-import com.sleepycat.db.*; --public class DbLsn extends Object { ... } -
A DbLsn is a log sequence number that is fully -encapsulated. The class itself has no methods, other than a default -constructor, so there is no way for the user to manipulate its data -directly. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/mem_class.html b/bdb/docs/api_java/mem_class.html deleted file mode 100644 index be9239defad..00000000000 --- a/bdb/docs/api_java/mem_class.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - -
-
-DbMemoryException- |
-
-
- |
-import com.sleepycat.db.*; --public class DbMemoryException extends DbException { ... } -
This manual page describes the DbMemoryException class and -how it is used by the various Db* classes. -
A DbMemoryException is thrown when there is insufficient memory -to complete an operation. -
This may or may not be recoverable. An example of where it would be -recoverable is during a Db.get or Dbc.get operation -with the Dbt flags set to Db.DB_DBT_USERMEM. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_fclose.html b/bdb/docs/api_java/memp_fclose.html deleted file mode 100644 index 5cf196d40dc..00000000000 --- a/bdb/docs/api_java/memp_fclose.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbMpoolFile.close- |
-
-
- |
-import com.sleepycat.db.*; -
A DbMpoolFile.close method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_fget.html b/bdb/docs/api_java/memp_fget.html deleted file mode 100644 index a59b4bbe84d..00000000000 --- a/bdb/docs/api_java/memp_fget.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbMpoolFile.get- |
-
-
- |
-import com.sleepycat.db.*; -
A DbMpoolFile.get method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_fopen.html b/bdb/docs/api_java/memp_fopen.html deleted file mode 100644 index e1186d50530..00000000000 --- a/bdb/docs/api_java/memp_fopen.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbMpoolFile.open- |
-
-
- |
-import com.sleepycat.db.*; -
A DbMpoolFile.open method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_fput.html b/bdb/docs/api_java/memp_fput.html deleted file mode 100644 index 64cb4732acc..00000000000 --- a/bdb/docs/api_java/memp_fput.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbMpoolFile.put- |
-
-
- |
-import com.sleepycat.db.*; -
A DbMpoolFile.put method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_fset.html b/bdb/docs/api_java/memp_fset.html deleted file mode 100644 index 3ab3ed0eec4..00000000000 --- a/bdb/docs/api_java/memp_fset.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbMpoolFile.set- |
-
-
- |
-import com.sleepycat.db.*; -
A DbMpoolFile.set method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_fsync.html b/bdb/docs/api_java/memp_fsync.html deleted file mode 100644 index b610635211f..00000000000 --- a/bdb/docs/api_java/memp_fsync.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbMpoolFile.sync- |
-
-
- |
-import com.sleepycat.db.*; -
A DbMpoolFile.sync method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_register.html b/bdb/docs/api_java/memp_register.html deleted file mode 100644 index 147b45a2001..00000000000 --- a/bdb/docs/api_java/memp_register.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbEnv.memp_register- |
-
-
- |
-import com.sleepycat.db.*; -
A DbEnv.memp_register method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_stat.html b/bdb/docs/api_java/memp_stat.html deleted file mode 100644 index 1314201a5c0..00000000000 --- a/bdb/docs/api_java/memp_stat.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - -
-
-DbEnv.memp_stat- |
-
-
- |
-import com.sleepycat.db.*; --public DbMpoolStat memp_stat() - throws DbException; -
-public DbMpoolFStat[] memp_fstat() - throws DbException; -
The DbEnv.memp_stat and DbEnv.memp_fstat method create statistical -structures and return to the caller. The statistics include the number -of files participating in the pool, the active pages in the pool, and -information as to how effective the cache has been. -
The DbEnv.memp_stat method creates a DbMpoolStat object containing global -statistics. The following data fields are available: -
The DbEnv.memp_fstat method creates an array of DbMpoolFStat objects -containing statistics for individual files in the pool. Each -DbMpoolFStat object contains statistics for an individual DbMpoolFile. -The following data fields are available for each DbMpoolFStat object: -
The DbEnv.memp_stat method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.memp_stat method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.memp_stat method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.memp_stat method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_sync.html b/bdb/docs/api_java/memp_sync.html deleted file mode 100644 index 6c729b8f570..00000000000 --- a/bdb/docs/api_java/memp_sync.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - -
-
-DbEnv.memp_sync- |
-
-
- |
-import com.sleepycat.db.*; -
A DbEnv.memp_sync method is not available in the Berkeley DB -Java API. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/memp_trickle.html b/bdb/docs/api_java/memp_trickle.html deleted file mode 100644 index 0eeae97d5c2..00000000000 --- a/bdb/docs/api_java/memp_trickle.html +++ /dev/null @@ -1,60 +0,0 @@ - - - - -
-
-DbEnv.memp_trickle- |
-
-
- |
-import com.sleepycat.db.*; --public int memp_trickle(int pct) - throws DbException; -
The DbEnv.memp_trickle method ensures that at least pct percent of -the pages in the shared memory pool are clean by writing dirty pages to -their backing files. -The number of pages that were written to reach the correct percentage is -returned. -
The purpose of the DbEnv.memp_trickle function is to enable a memory -pool manager to ensure that a page is always available for reading in new -information without having to wait for a write. -
The DbEnv.memp_trickle method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.memp_trickle method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.memp_trickle method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.memp_trickle method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/pindex.src b/bdb/docs/api_java/pindex.src deleted file mode 100644 index 2dd85859dcf..00000000000 --- a/bdb/docs/api_java/pindex.src +++ /dev/null @@ -1,249 +0,0 @@ -__APIREL__/api_java/db_class.html#2 @Db -__APIREL__/api_java/db_class.html#Db.DB_XA_CREATE Db@Db.DB_XA_CREATE -__APIREL__/api_java/dbc_class.html#2 @Dbc -__APIREL__/api_java/dbenv_class.html#2 @DbEnv -__APIREL__/api_java/dbenv_class.html#Db.DB_CLIENT DbEnv@Db.DB_CLIENT -__APIREL__/api_java/dbt_class.html#2 @Dbt -__APIREL__/api_java/dbt_class.html#3 @key/data pairs -__APIREL__/api_java/dbt_class.html#data Dbt@data -__APIREL__/api_java/dbt_class.html#Db.DB_DBT_MALLOC Dbt@Db.DB_DBT_MALLOC -__APIREL__/api_java/dbt_class.html#Db.DB_DBT_REALLOC Dbt@Db.DB_DBT_REALLOC -__APIREL__/api_java/dbt_class.html#Db.DB_DBT_USERMEM Dbt@Db.DB_DBT_USERMEM -__APIREL__/api_java/dbt_class.html#Db.DB_DBT_PARTIAL Dbt@Db.DB_DBT_PARTIAL -__APIREL__/api_java/dbt_class.html#4 logical @record number format -__APIREL__/api_java/deadlock_class.html#2 @DbDeadlockException -__APIREL__/api_java/env_set_error_stream.html#2 @DbEnv.set_error_stream -__APIREL__/api_java/except_class.html#2 @DbException -__APIREL__/api_java/get_errno.html#2 @DbException.get_errno -__APIREL__/api_java/lock_class.html#2 @DbLock -__APIREL__/api_java/lsn_class.html#2 @DbLsn -__APIREL__/api_java/mem_class.html#2 @DbMemoryException -__APIREL__/api_java/runrec_class.html#2 @DbRunRecoveryException -__APIREL__/api_java/txn_class.html#2 @DbTxn -__APIREL__/api_java/db_close.html#2 @Db.close -__APIREL__/api_java/db_close.html#Db.DB_NOSYNC Db.close@Db.DB_NOSYNC -__APIREL__/api_java/db_close.html#3 Db.close @DB_INCOMPLETE -__APIREL__/api_java/db_cursor.html#2 @Db.cursor -__APIREL__/api_java/db_cursor.html#Db.DB_WRITECURSOR Db.cursor@Db.DB_WRITECURSOR -__APIREL__/api_java/db_del.html#2 @Db.del -__APIREL__/api_java/db_fd.html#2 @Db.fd -__APIREL__/api_java/db_get.html#2 @Db.get -__APIREL__/api_java/db_get.html#Db.DB_CONSUME Db.get@Db.DB_CONSUME -__APIREL__/api_java/db_get.html#Db.DB_CONSUME_WAIT Db.get@Db.DB_CONSUME_WAIT -__APIREL__/api_java/db_get.html#Db.DB_GET_BOTH Db.get@Db.DB_GET_BOTH -__APIREL__/api_java/db_get.html#Db.DB_SET_RECNO Db.get@Db.DB_SET_RECNO -__APIREL__/api_java/db_get.html#Db.DB_RMW Db.get@Db.DB_RMW -__APIREL__/api_java/db_get_byteswapped.html#2 @Db.get_byteswapped -__APIREL__/api_java/db_get_type.html#2 @Db.get_type -__APIREL__/api_java/db_join.html#2 @Db.join -__APIREL__/api_java/db_join.html#Db.DB_JOIN_NOSORT Db.join@Db.DB_JOIN_NOSORT -__APIREL__/api_java/db_join.html#Db.DB_JOIN_ITEM Db.join@Db.DB_JOIN_ITEM -__APIREL__/api_java/db_join.html#Db.DB_RMW Db.join@Db.DB_RMW -__APIREL__/api_java/db_key_range.html#2 @Db.key_range -__APIREL__/api_java/db_open.html#2 @Db.open -__APIREL__/api_java/db_open.html#Db.DB_CREATE Db.open@Db.DB_CREATE -__APIREL__/api_java/db_open.html#Db.DB_EXCL Db.open@Db.DB_EXCL -__APIREL__/api_java/db_open.html#Db.DB_NOMMAP Db.open@Db.DB_NOMMAP -__APIREL__/api_java/db_open.html#Db.DB_RDONLY Db.open@Db.DB_RDONLY -__APIREL__/api_java/db_open.html#Db.DB_THREAD Db.open@Db.DB_THREAD -__APIREL__/api_java/db_open.html#Db.DB_TRUNCATE Db.open@Db.DB_TRUNCATE -__APIREL__/api_java/db_open.html#Db.DB_OLD_VERSION Db.open@Db.DB_OLD_VERSION -__APIREL__/api_java/db_put.html#2 @Db.put -__APIREL__/api_java/db_put.html#Db.DB_APPEND Db.put@Db.DB_APPEND -__APIREL__/api_java/db_put.html#Db.DB_NODUPDATA Db.put@Db.DB_NODUPDATA -__APIREL__/api_java/db_put.html#Db.DB_NOOVERWRITE Db.put@Db.DB_NOOVERWRITE -__APIREL__/api_java/db_remove.html#2 @Db.remove -__APIREL__/api_java/db_rename.html#2 @Db.rename -__APIREL__/api_java/db_set_append_recno.html#2 @Db.set_append_recno -__APIREL__/api_java/db_set_bt_compare.html#2 @Db.set_bt_compare -__APIREL__/api_java/db_set_bt_minkey.html#2 @Db.set_bt_minkey -__APIREL__/api_java/db_set_bt_prefix.html#2 @Db.set_bt_prefix -__APIREL__/api_java/db_set_cachesize.html#2 @Db.set_cachesize -__APIREL__/api_java/db_set_dup_compare.html#2 @Db.set_dup_compare -__APIREL__/api_java/db_set_errcall.html#2 @Db.set_errcall -__APIREL__/api_java/db_set_errpfx.html#2 @Db.set_errpfx -__APIREL__/api_java/db_set_feedback.html#2 @Db.set_feedback -__APIREL__/api_java/db_set_feedback.html#Db.DB_UPGRADE Db.set_feedback@Db.DB_UPGRADE -__APIREL__/api_java/db_set_feedback.html#Db.DB_VERIFY Db.set_feedback@Db.DB_VERIFY -__APIREL__/api_java/db_set_flags.html#2 @Db.set_flags -__APIREL__/api_java/db_set_flags.html#Db.DB_DUP Db.set_flags@Db.DB_DUP -__APIREL__/api_java/db_set_flags.html#Db.DB_DUPSORT Db.set_flags@Db.DB_DUPSORT -__APIREL__/api_java/db_set_flags.html#Db.DB_RECNUM Db.set_flags@Db.DB_RECNUM -__APIREL__/api_java/db_set_flags.html#Db.DB_REVSPLITOFF Db.set_flags@Db.DB_REVSPLITOFF -__APIREL__/api_java/db_set_flags.html#Db.DB_DUP Db.set_flags@Db.DB_DUP -__APIREL__/api_java/db_set_flags.html#Db.DB_DUPSORT Db.set_flags@Db.DB_DUPSORT -__APIREL__/api_java/db_set_flags.html#Db.DB_RENUMBER Db.set_flags@Db.DB_RENUMBER -__APIREL__/api_java/db_set_flags.html#Db.DB_SNAPSHOT Db.set_flags@Db.DB_SNAPSHOT -__APIREL__/api_java/db_set_h_ffactor.html#2 @Db.set_h_ffactor -__APIREL__/api_java/db_set_h_hash.html#2 @Db.set_h_hash -__APIREL__/api_java/db_set_h_nelem.html#2 @Db.set_h_nelem -__APIREL__/api_java/db_set_lorder.html#2 @Db.set_lorder -__APIREL__/api_java/db_set_pagesize.html#2 @Db.set_pagesize -__APIREL__/api_java/db_set_q_extentsize.html#2 @Db.set_q_extentsize -__APIREL__/api_java/db_set_re_delim.html#2 @Db.set_re_delim -__APIREL__/api_java/db_set_re_len.html#2 @Db.set_re_len -__APIREL__/api_java/db_set_re_pad.html#2 @Db.set_re_pad -__APIREL__/api_java/db_set_re_source.html#2 @Db.set_re_source -__APIREL__/api_java/db_stat.html#2 @Db.stat -__APIREL__/api_java/db_stat.html#Db.DB_CACHED_COUNTS Db.stat@Db.DB_CACHED_COUNTS -__APIREL__/api_java/db_stat.html#Db.DB_RECORDCOUNT Db.stat@Db.DB_RECORDCOUNT -__APIREL__/api_java/db_sync.html#2 @Db.sync -__APIREL__/api_java/db_upgrade.html#2 @Db.upgrade -__APIREL__/api_java/db_upgrade.html#Db.DB_DUPSORT Db.upgrade@Db.DB_DUPSORT -__APIREL__/api_java/db_upgrade.html#Db.DB_OLD_VERSION Db.upgrade@Db.DB_OLD_VERSION -__APIREL__/api_java/db_verify.html#2 @Db.verify -__APIREL__/api_java/db_verify.html#Db.DB_SALVAGE Db.verify@Db.DB_SALVAGE -__APIREL__/api_java/db_verify.html#Db.DB_AGGRESSIVE Db.verify@Db.DB_AGGRESSIVE -__APIREL__/api_java/db_verify.html#Db.DB_NOORDERCHK Db.verify@Db.DB_NOORDERCHK -__APIREL__/api_java/db_verify.html#Db.DB_ORDERCHKONLY Db.verify@Db.DB_ORDERCHKONLY -__APIREL__/api_java/dbc_close.html#2 @Dbc.close -__APIREL__/api_java/dbc_count.html#2 @Dbc.count -__APIREL__/api_java/dbc_del.html#2 @Dbc.del -__APIREL__/api_java/dbc_dup.html#2 @Dbc.dup -__APIREL__/api_java/dbc_dup.html#Db.DB_POSITION Dbc.dup@Db.DB_POSITION -__APIREL__/api_java/dbc_get.html#2 @Dbc.get -__APIREL__/api_java/dbc_get.html#Db.DB_CURRENT Dbc.get@Db.DB_CURRENT -__APIREL__/api_java/dbc_get.html#Db.DB_FIRST Dbc.get@Db.DB_FIRST -__APIREL__/api_java/dbc_get.html#Db.DB_LAST Dbc.get@Db.DB_LAST -__APIREL__/api_java/dbc_get.html#Db.DB_GET_BOTH Dbc.get@Db.DB_GET_BOTH -__APIREL__/api_java/dbc_get.html#Db.DB_GET_RECNO Dbc.get@Db.DB_GET_RECNO -__APIREL__/api_java/dbc_get.html#Db.DB_JOIN_ITEM Dbc.get@Db.DB_JOIN_ITEM -__APIREL__/api_java/dbc_get.html#Db.DB_NEXT Dbc.get@Db.DB_NEXT -__APIREL__/api_java/dbc_get.html#Db.DB_PREV Dbc.get@Db.DB_PREV -__APIREL__/api_java/dbc_get.html#Db.DB_NEXT_DUP Dbc.get@Db.DB_NEXT_DUP -__APIREL__/api_java/dbc_get.html#Db.DB_NEXT_NODUP Dbc.get@Db.DB_NEXT_NODUP -__APIREL__/api_java/dbc_get.html#Db.DB_PREV_NODUP Dbc.get@Db.DB_PREV_NODUP -__APIREL__/api_java/dbc_get.html#Db.DB_SET Dbc.get@Db.DB_SET -__APIREL__/api_java/dbc_get.html#Db.DB_SET_RANGE Dbc.get@Db.DB_SET_RANGE -__APIREL__/api_java/dbc_get.html#Db.DB_SET_RECNO Dbc.get@Db.DB_SET_RECNO -__APIREL__/api_java/dbc_get.html#Db.DB_RMW Dbc.get@Db.DB_RMW -__APIREL__/api_java/dbc_put.html#2 @Dbc.put -__APIREL__/api_java/dbc_put.html#Db.DB_AFTER Dbc.put@Db.DB_AFTER -__APIREL__/api_java/dbc_put.html#Db.DB_BEFORE Dbc.put@Db.DB_BEFORE -__APIREL__/api_java/dbc_put.html#Db.DB_CURRENT Dbc.put@Db.DB_CURRENT -__APIREL__/api_java/dbc_put.html#Db.DB_KEYFIRST Dbc.put@Db.DB_KEYFIRST -__APIREL__/api_java/dbc_put.html#Db.DB_KEYLAST Dbc.put@Db.DB_KEYLAST -__APIREL__/api_java/dbc_put.html#Db.DB_NODUPDATA Dbc.put@Db.DB_NODUPDATA -__APIREL__/api_java/env_close.html#2 @DbEnv.close -__APIREL__/api_java/env_open.html#2 @DbEnv.open -__APIREL__/api_java/env_open.html#Db.DB_JOINENV DbEnv.open@Db.DB_JOINENV -__APIREL__/api_java/env_open.html#Db.DB_INIT_CDB DbEnv.open@Db.DB_INIT_CDB -__APIREL__/api_java/env_open.html#Db.DB_INIT_LOCK DbEnv.open@Db.DB_INIT_LOCK -__APIREL__/api_java/env_open.html#Db.DB_INIT_LOG DbEnv.open@Db.DB_INIT_LOG -__APIREL__/api_java/env_open.html#Db.DB_INIT_MPOOL DbEnv.open@Db.DB_INIT_MPOOL -__APIREL__/api_java/env_open.html#Db.DB_INIT_TXN DbEnv.open@Db.DB_INIT_TXN -__APIREL__/api_java/env_open.html#Db.DB_RECOVER DbEnv.open@Db.DB_RECOVER -__APIREL__/api_java/env_open.html#Db.DB_RECOVER_FATAL DbEnv.open@Db.DB_RECOVER_FATAL -__APIREL__/api_java/env_open.html#Db.DB_USE_ENVIRON DbEnv.open@Db.DB_USE_ENVIRON -__APIREL__/api_java/env_open.html#Db.DB_USE_ENVIRON_ROOT DbEnv.open@Db.DB_USE_ENVIRON_ROOT -__APIREL__/api_java/env_open.html#Db.DB_CREATE DbEnv.open@Db.DB_CREATE -__APIREL__/api_java/env_open.html#Db.DB_LOCKDOWN DbEnv.open@Db.DB_LOCKDOWN -__APIREL__/api_java/env_open.html#Db.DB_PRIVATE DbEnv.open@Db.DB_PRIVATE -__APIREL__/api_java/env_open.html#Db.DB_SYSTEM_MEM DbEnv.open@Db.DB_SYSTEM_MEM -__APIREL__/api_java/env_open.html#Db.DB_THREAD DbEnv.open@Db.DB_THREAD -__APIREL__/api_java/env_remove.html#2 @DbEnv.remove -__APIREL__/api_java/env_remove.html#Db.DB_FORCE DbEnv.remove@Db.DB_FORCE -__APIREL__/api_java/env_remove.html#Db.DB_USE_ENVIRON DbEnv.remove@Db.DB_USE_ENVIRON -__APIREL__/api_java/env_remove.html#Db.DB_USE_ENVIRON_ROOT DbEnv.remove@Db.DB_USE_ENVIRON_ROOT -__APIREL__/api_java/env_set_cachesize.html#2 @DbEnv.set_cachesize -__APIREL__/api_java/env_set_data_dir.html#2 @DbEnv.set_data_dir -__APIREL__/api_java/env_set_errcall.html#2 @DbEnv.set_errcall -__APIREL__/api_java/env_set_errpfx.html#2 @DbEnv.set_errpfx -__APIREL__/api_java/env_set_feedback.html#2 @DbEnv.set_feedback -__APIREL__/api_java/env_set_feedback.html#Db.DB_RECOVER DbEnv.set_feedback@Db.DB_RECOVER -__APIREL__/api_java/env_set_flags.html#2 @DbEnv.set_flags -__APIREL__/api_java/env_set_flags.html#Db.DB_CDB_ALLDB DbEnv.set_flags@Db.DB_CDB_ALLDB -__APIREL__/api_java/env_set_flags.html#Db.DB_NOMMAP DbEnv.set_flags@Db.DB_NOMMAP -__APIREL__/api_java/env_set_flags.html#Db.DB_TXN_NOSYNC DbEnv.set_flags@Db.DB_TXN_NOSYNC -__APIREL__/api_java/env_set_lg_bsize.html#2 @DbEnv.set_lg_bsize -__APIREL__/api_java/env_set_lg_dir.html#2 @DbEnv.set_lg_dir -__APIREL__/api_java/env_set_lg_max.html#2 @DbEnv.set_lg_max -__APIREL__/api_java/env_set_lk_conflicts.html#2 @DbEnv.set_lk_conflicts -__APIREL__/api_java/env_set_lk_detect.html#2 @DbEnv.set_lk_detect -__APIREL__/api_java/env_set_lk_detect.html#DB_LOCK_DEFAULT DbEnv.set_lk_detect@DB_LOCK_DEFAULT -__APIREL__/api_java/env_set_lk_detect.html#DB_LOCK_OLDEST DbEnv.set_lk_detect@DB_LOCK_OLDEST -__APIREL__/api_java/env_set_lk_detect.html#DB_LOCK_RANDOM DbEnv.set_lk_detect@DB_LOCK_RANDOM -__APIREL__/api_java/env_set_lk_detect.html#DB_LOCK_YOUNGEST DbEnv.set_lk_detect@DB_LOCK_YOUNGEST -__APIREL__/api_java/env_set_lk_max.html#2 @DbEnv.set_lk_max -__APIREL__/api_java/env_set_lk_max_locks.html#2 @DbEnv.set_lk_max_locks -__APIREL__/api_java/env_set_lk_max_lockers.html#2 @DbEnv.set_lk_max_lockers -__APIREL__/api_java/env_set_lk_max_objects.html#2 @DbEnv.set_lk_max_objects -__APIREL__/api_java/env_set_mp_mmapsize.html#2 @DbEnv.set_mp_mmapsize -__APIREL__/api_java/env_set_mutexlocks.html#2 @DbEnv.set_mutexlocks -__APIREL__/api_java/env_set_pageyield.html#2 @DbEnv.set_pageyield -__APIREL__/api_java/env_set_panicstate.html#2 @DbEnv.set_panicstate -__APIREL__/api_java/env_set_rec_init.html#2 @DbEnv.set_recovery_init -__APIREL__/api_java/env_set_region_init.html#2 @DbEnv.set_region_init -__APIREL__/api_java/env_set_server.html#2 @DbEnv.set_server -__APIREL__/api_java/env_set_server.html#DB_NOSERVER DbEnv.set_server@DB_NOSERVER -__APIREL__/api_java/env_set_server.html#DB_NOSERVER_ID DbEnv.set_server@DB_NOSERVER_ID -__APIREL__/api_java/env_set_shm_key.html#2 @DbEnv.set_shm_key -__APIREL__/api_java/env_set_tas_spins.html#2 @DbEnv.set_tas_spins -__APIREL__/api_java/env_set_tmp_dir.html#2 @DbEnv.set_tmp_dir -__APIREL__/api_java/env_set_tx_max.html#2 @DbEnv.set_tx_max -__APIREL__/api_java/env_set_tx_recover.html#2 @DbEnv.set_tx_recover -__APIREL__/api_java/env_set_tx_recover.html#Db.DB_TXN_BACKWARD_ROLL DbEnv.set_tx_recover@Db.DB_TXN_BACKWARD_ROLL -__APIREL__/api_java/env_set_tx_recover.html#Db.DB_TXN_FORWARD_ROLL DbEnv.set_tx_recover@Db.DB_TXN_FORWARD_ROLL -__APIREL__/api_java/env_set_tx_recover.html#Db.DB_TXN_ABORT DbEnv.set_tx_recover@Db.DB_TXN_ABORT -__APIREL__/api_java/env_set_tx_timestamp.html#2 @DbEnv.set_tx_timestamp -__APIREL__/api_java/env_set_verbose.html#2 @DbEnv.set_verbose -__APIREL__/api_java/env_set_verbose.html#Db.DB_VERB_CHKPOINT DbEnv.set_verbose@Db.DB_VERB_CHKPOINT -__APIREL__/api_java/env_set_verbose.html#Db.DB_VERB_DEADLOCK DbEnv.set_verbose@Db.DB_VERB_DEADLOCK -__APIREL__/api_java/env_set_verbose.html#Db.DB_VERB_RECOVERY DbEnv.set_verbose@Db.DB_VERB_RECOVERY -__APIREL__/api_java/env_set_verbose.html#Db.DB_VERB_WAITSFOR DbEnv.set_verbose@Db.DB_VERB_WAITSFOR -__APIREL__/api_java/env_strerror.html#2 @DbEnv.strerror -__APIREL__/api_java/env_version.html#2 @DbEnv.get_version_major -__APIREL__/api_java/lock_detect.html#2 @DbEnv.lock_detect -__APIREL__/api_java/lock_detect.html#Db.DB_LOCK_CONFLICT DbEnv.lock_detect@Db.DB_LOCK_CONFLICT -__APIREL__/api_java/lock_get.html#2 @DbEnv.lock_get -__APIREL__/api_java/lock_get.html#Db.DB_LOCK_NOWAIT DbEnv.lock_get@Db.DB_LOCK_NOWAIT -__APIREL__/api_java/lock_get.html#Db.DB_LOCK_NOTGRANTED DbEnv.lock_get@Db.DB_LOCK_NOTGRANTED -__APIREL__/api_java/lock_id.html#2 @DbEnv.lock_id -__APIREL__/api_java/lock_put.html#2 @DbLock.put -__APIREL__/api_java/lock_stat.html#2 @DbEnv.lock_stat -__APIREL__/api_java/lock_vec.html#2 @DbEnv.lock_vec -__APIREL__/api_java/log_archive.html#2 @DbEnv.log_archive -__APIREL__/api_java/log_archive.html#Db.DB_ARCH_ABS DbEnv.log_archive@Db.DB_ARCH_ABS -__APIREL__/api_java/log_archive.html#Db.DB_ARCH_DATA DbEnv.log_archive@Db.DB_ARCH_DATA -__APIREL__/api_java/log_archive.html#Db.DB_ARCH_LOG DbEnv.log_archive@Db.DB_ARCH_LOG -__APIREL__/api_java/log_compare.html#2 @DbEnv.log_compare -__APIREL__/api_java/log_file.html#2 @DbEnv.log_file -__APIREL__/api_java/log_flush.html#2 @DbEnv.log_flush -__APIREL__/api_java/log_get.html#2 @DbEnv.log_get -__APIREL__/api_java/log_get.html#Db.DB_CHECKPOINT DbEnv.log_get@Db.DB_CHECKPOINT -__APIREL__/api_java/log_get.html#Db.DB_FIRST DbEnv.log_get@Db.DB_FIRST -__APIREL__/api_java/log_get.html#Db.DB_LAST DbEnv.log_get@Db.DB_LAST -__APIREL__/api_java/log_get.html#Db.DB_NEXT DbEnv.log_get@Db.DB_NEXT -__APIREL__/api_java/log_get.html#Db.DB_PREV DbEnv.log_get@Db.DB_PREV -__APIREL__/api_java/log_get.html#Db.DB_CURRENT DbEnv.log_get@Db.DB_CURRENT -__APIREL__/api_java/log_get.html#Db.DB_SET DbEnv.log_get@Db.DB_SET -__APIREL__/api_java/log_put.html#2 @DbEnv.log_put -__APIREL__/api_java/log_put.html#Db.DB_CHECKPOINT DbEnv.log_put@Db.DB_CHECKPOINT -__APIREL__/api_java/log_put.html#Db.DB_CURLSN DbEnv.log_put@Db.DB_CURLSN -__APIREL__/api_java/log_put.html#Db.DB_FLUSH DbEnv.log_put@Db.DB_FLUSH -__APIREL__/api_java/log_register.html#2 @DbEnv.log_register -__APIREL__/api_java/log_stat.html#2 @DbEnv.log_stat -__APIREL__/api_java/log_unregister.html#2 @DbEnv.log_unregister -__APIREL__/api_java/memp_fclose.html#2 @DbMpoolFile.close -__APIREL__/api_java/memp_fget.html#2 @DbMpoolFile.get -__APIREL__/api_java/memp_fopen.html#2 @DbMpoolFile.open -__APIREL__/api_java/memp_fput.html#2 @DbMpoolFile.put -__APIREL__/api_java/memp_fset.html#2 @DbMpoolFile.set -__APIREL__/api_java/memp_fsync.html#2 @DbMpoolFile.sync -__APIREL__/api_java/memp_register.html#2 @DbEnv.memp_register -__APIREL__/api_java/memp_stat.html#2 @DbEnv.memp_stat -__APIREL__/api_java/memp_sync.html#2 @DbEnv.memp_sync -__APIREL__/api_java/memp_trickle.html#2 @DbEnv.memp_trickle -__APIREL__/api_java/txn_abort.html#2 @DbTxn.abort -__APIREL__/api_java/txn_begin.html#2 @DbEnv.txn_begin -__APIREL__/api_java/txn_begin.html#Db.DB_TXN_NOSYNC DbEnv.txn_begin@Db.DB_TXN_NOSYNC -__APIREL__/api_java/txn_begin.html#Db.DB_TXN_NOWAIT DbEnv.txn_begin@Db.DB_TXN_NOWAIT -__APIREL__/api_java/txn_begin.html#Db.DB_TXN_SYNC DbEnv.txn_begin@Db.DB_TXN_SYNC -__APIREL__/api_java/txn_checkpoint.html#2 @DbEnv.txn_checkpoint -__APIREL__/api_java/txn_checkpoint.html#Db.DB_FORCE DbEnv.txn_checkpoint@Db.DB_FORCE -__APIREL__/api_java/txn_commit.html#2 @DbTxn.commit -__APIREL__/api_java/txn_commit.html#Db.DB_TXN_NOSYNC DbTxn.commit@Db.DB_TXN_NOSYNC -__APIREL__/api_java/txn_commit.html#Db.DB_TXN_SYNC DbTxn.commit@Db.DB_TXN_SYNC -__APIREL__/api_java/txn_id.html#2 @DbTxn.id -__APIREL__/api_java/txn_prepare.html#2 @DbTxn.prepare -__APIREL__/api_java/txn_stat.html#2 @DbEnv.txn_stat diff --git a/bdb/docs/api_java/runrec_class.html b/bdb/docs/api_java/runrec_class.html deleted file mode 100644 index 31fd07b9493..00000000000 --- a/bdb/docs/api_java/runrec_class.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - -
-
-DbRunRecoveryException- |
-
-
- |
-import com.sleepycat.db.*; --public class DbRunRecoveryException extends DbException { ... } -
This manual page describes the DbRunRecoveryException class and -how it is used by the various Db* classes. -
Errors can occur in the Berkeley DB library where the only solution is to shut -down the application and run recovery. (For example, if Berkeley DB is unable -to write log records to disk because there is insufficient disk space.) -When a fatal error occurs in Berkeley DB, methods will throw a -DbRunRecoveryException, at which point all subsequent database -calls will also fail in the same way. When this occurs, recovery should -be performed. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_abort.html b/bdb/docs/api_java/txn_abort.html deleted file mode 100644 index 48f4ddf0784..00000000000 --- a/bdb/docs/api_java/txn_abort.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - -
-
-DbTxn.abort- |
-
-
- |
-import com.sleepycat.db.*; --public void abort() - throws DbException; -
The DbTxn.abort method causes an abnormal termination of the -transaction. The log is played backwards and any necessary recovery -operations are initiated through the recover function specified -to DbEnv.open. After the log processing is completed, all locks -held by the transaction are released. As is the case for -DbTxn.commit, applications that require strict two-phase locking -should not explicitly release any locks. -
In the case of nested transactions, aborting a parent transaction causes -all children (unresolved or not) of the parent transaction to be aborted. -
Once the DbTxn.abort method returns, the DbTxn handle may not -be accessed again. -
The DbTxn.abort method throws an exception that encapsulates a non-zero error value on -failure. -
The DbTxn.abort method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbTxn.abort method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_begin.html b/bdb/docs/api_java/txn_begin.html deleted file mode 100644 index f81e86aeaae..00000000000 --- a/bdb/docs/api_java/txn_begin.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - -
-
-DbEnv.txn_begin- |
-
-
- |
-import com.sleepycat.db.*; --public DbTxn txn_begin(DbTxn parent, int flags) - throws DbException; -
The DbEnv.txn_begin method creates a new transaction in the environment -and returns a DbTxn that uniquely identifies it. -
If the parent argument is non-null, the new transaction will -be a nested transaction, with the transaction indicated by -parent as its parent. Transactions may be -nested to any level. -
The flags parameter must be set to 0 or one of the following -values: -
This behavior may be set for an entire Berkeley DB environment as part of the -DbEnv.set_flags interface. -
This behavior is the default for Berkeley DB environments unless the -Db.DB_TXN_NOSYNC flag was specified to the DbEnv.set_flags -interface. -
Note: An transaction may not span threads, -i.e., each transaction must begin and end in the same thread, and each -transaction may only be used by a single thread. -
Note: cursors may not span transactions, i.e., each cursor must be opened -and closed within a single transaction. -
Note: a parent transaction may not issue any Berkeley DB operations, except for -DbEnv.txn_begin, DbTxn.abort and DbTxn.commit, while it has -active child transactions (child transactions that have not yet been -committed or aborted). -
The DbEnv.txn_begin method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.txn_begin method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.txn_begin method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.txn_begin method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_checkpoint.html b/bdb/docs/api_java/txn_checkpoint.html deleted file mode 100644 index f2bc7528aba..00000000000 --- a/bdb/docs/api_java/txn_checkpoint.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - -
-
-DbEnv.txn_checkpoint- |
-
-
- |
-import com.sleepycat.db.*; --int -public int txn_checkpoint(int kbyte, int min, int flags) - throws DbException; -
The DbEnv.txn_checkpoint method flushes the underlying memory pool, -writes a checkpoint record to the log and then flushes the log. -
If either kbyte or min is non-zero, the checkpoint is only -done if there has been activity since the last checkpoint and either -more than min minutes have passed since the last checkpoint, -or if more than kbyte kilobytes of log data have been written since -the last checkpoint. -
The flags parameter must be set to 0 or one of the following -values: -
The DbEnv.txn_checkpoint method throws an exception that encapsulates a non-zero error value on -failure, and returns Db.DB_INCOMPLETE if there were pages that needed to be -written to complete the checkpoint but that DbEnv.memp_sync was unable -to write immediately. -
The DbEnv.txn_checkpoint method may fail and throw an exception encapsulating a non-zero error for the following conditions: -
The DbEnv.txn_checkpoint method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.txn_checkpoint method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_class.html b/bdb/docs/api_java/txn_class.html deleted file mode 100644 index ab386172bff..00000000000 --- a/bdb/docs/api_java/txn_class.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - -
-
-DbTxn- |
-
-
- |
-import com.sleepycat.db.*; --public class DbTxn extends Object { ... } -
This manual page describes the specific details of the DbTxn class. -
The DbEnv transaction methods and the DbTxn class provide -transaction semantics. Full transaction support is provided by a -collection of modules that provide interfaces to the services required -for transaction processing. These services are recovery, concurrency -control and the management of shared data. -
Transaction semantics can be applied to the access methods described in -Db through method call parameters. -
The model intended for transactional use (and the one that is used by -the access methods) is write-ahead logging to record both before- and -after-images. Locking follows a two-phase protocol, with all locks being -released at transaction commit. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_commit.html b/bdb/docs/api_java/txn_commit.html deleted file mode 100644 index 53aa0df4622..00000000000 --- a/bdb/docs/api_java/txn_commit.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - -
-
-DbTxn.commit- |
-
-
- |
-import com.sleepycat.db.*; --public void commit(u_int32_t flags) - throws DbException; -
The DbTxn.commit method ends the transaction. In the case of nested -transactions, if the transaction is a parent transaction, committing -the parent transaction causes all unresolved children of the parent to -be committed. -
In the case of nested transactions, if the transaction is a child -transaction, its locks are not released, but are acquired by its parent. -While the commit of the child transaction will succeed, the actual -resolution of the child transaction is postponed until the parent -transaction is committed or aborted, i.e., if its parent transaction -commits, it will be committed, and if its parent transaction aborts, it -will be aborted. -
The flags parameter must be set to 0 or one of the following -values: -
This behavior may be set for an entire Berkeley DB environment as part of the -DbEnv.set_flags interface. -
This behavior is the default for Berkeley DB environments unless the -Db.DB_TXN_NOSYNC flag was specified to the DbEnv.set_flags -or DbEnv.txn_begin interfaces. -
Once the DbTxn.commit method returns, the DbTxn handle may not -be accessed again. If DbTxn.commit encounters an error, the -transaction and all child transactions of the transaction are aborted. -
The DbTxn.commit method throws an exception that encapsulates a non-zero error value on -failure. -
The DbTxn.commit method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbTxn.commit method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_id.html b/bdb/docs/api_java/txn_id.html deleted file mode 100644 index 89fc62a37b6..00000000000 --- a/bdb/docs/api_java/txn_id.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - -
-
-DbTxn.id- |
-
-
- |
-import com.sleepycat.db.*; --public int id() - throws DbException; -
The DbTxn.id method returns the unique transaction id associated with the -specified transaction. Locking calls made on behalf of this transaction -should use the value returned from DbTxn.id as the locker parameter -to the DbEnv.lock_get or DbEnv.lock_vec calls. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_prepare.html b/bdb/docs/api_java/txn_prepare.html deleted file mode 100644 index 09feae726d6..00000000000 --- a/bdb/docs/api_java/txn_prepare.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - -
-
-DbTxn.prepare- |
-
-
- |
-import com.sleepycat.db.*; --public void prepare() - throws DbException; -
The DbTxn.prepare method initiates the beginning of a two-phase commit. -
In a distributed transaction environment, Berkeley DB can be used as a local -transaction manager. In this case, the distributed transaction manager -must send prepare messages to each local manager. The local -manager must then issue a DbTxn.prepare and await its successful -return before responding to the distributed transaction manager. Only -after the distributed transaction manager receives successful responses -from all of its prepare messages should it issue any -commit messages. -
In the case of nested transactions, preparing a parent transaction -causes all unresolved children of the parent transaction to be prepared. -
The DbTxn.prepare method throws an exception that encapsulates a non-zero error value on -failure. -
The DbTxn.prepare method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbTxn.prepare method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_java/txn_stat.html b/bdb/docs/api_java/txn_stat.html deleted file mode 100644 index cb033ccde82..00000000000 --- a/bdb/docs/api_java/txn_stat.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - -
-
-DbEnv.txn_stat- |
-
-
- |
-import com.sleepycat.db.*; --public DbTxnStat txn_stat() - throws DbException; -
The DbEnv.txn_stat method -creates a DbTxnStat object encapsulating a statistical structure. -The transaction region statistics are stored in a DbTxnStat object. -The following data fields are available from the DbTxnStat object: -
Statistical structures are created in allocated memory. If db_malloc is non-NULL, it -is called to allocate the memory, otherwise, the library function -malloc(3) is used. The function db_malloc must match -the calling conventions of the malloc(3) library routine. -Regardless, the caller is responsible for deallocating the returned -memory. To deallocate returned memory, free the returned memory -reference, references inside the returned memory do not need to be -individually freed. -
The transaction region statistics are stored in a structure of type -DB_TXN_STAT. The following DB_TXN_STAT fields will be filled in: -
The DbEnv.txn_stat method throws an exception that encapsulates a non-zero error value on -failure. -
The DbEnv.txn_stat method may fail and throw an exception for errors specified for other Berkeley DB and C library or system methods. -If a catastrophic error has occurred, the DbEnv.txn_stat method may fail and throw -a DbRunRecoveryException, in which case all subsequent Berkeley DB calls -will fail in the same way. -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_close.html b/bdb/docs/api_tcl/db_close.html deleted file mode 100644 index eaae3165588..00000000000 --- a/bdb/docs/api_tcl/db_close.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - -
-
-db close- |
-
-
- |
db close - [-nosync] -
The db close command flushes any cached database information to -disk, closes any open cursors, frees any allocated resources, and closes -any underlying files. Since key/data pairs are cached in memory, failing -to sync the file with the db close or db sync command may -result in inconsistent or lost information. -
The options are as follows: -
The -nosync flag is a dangerous option. It should only be set if the -application is doing logging (with transactions) so that the database is -recoverable after a system or application crash, or if the database is -always generated from scratch after any system or application crash. -
It is important to understand that flushing cached information to disk -only minimizes the window of opportunity for corrupted data. While -unlikely, it is possible for database corruption to happen if a system or -application crash occurs while writing data to the database. To ensure -that database corruption never occurs, applications must either: use -transactions and logging with automatic recovery, use logging and -application-specific recovery, or edit a copy of the database, and, once -all applications using the database have successfully called -db close, atomically replace the original database with the updated -copy. -
Once db close has been called, regardless of its return, the DB -handle may not be accessed again. -
The db close command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_count.html b/bdb/docs/api_tcl/db_count.html deleted file mode 100644 index 123c030ccff..00000000000 --- a/bdb/docs/api_tcl/db_count.html +++ /dev/null @@ -1,38 +0,0 @@ - - - - - -
-
-db count- |
-
-
- |
db count key -
The db count command returns a count of the number -of duplicate data items for the key given. -If the key does not exist, a value of 0 is returned. -If there are no duplicates, or the database does not support -duplicates, but a key/data pair exists, a value of 1 is returned. -If an error occurs, a Berkeley DB error message is returned or a Tcl error is -thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_cursor.html b/bdb/docs/api_tcl/db_cursor.html deleted file mode 100644 index 79187650dda..00000000000 --- a/bdb/docs/api_tcl/db_cursor.html +++ /dev/null @@ -1,42 +0,0 @@ - - - - - -
-
-db cursor- |
-
-
- |
db cursor - [-txn txnid] -
The db cursor command creates a database cursor. The returned -cursor handle is bound to a Tcl command of the form dbN.cX, where -X is an integer starting at 0 (e.g., db0.c0 and db0.c1). It is through -this Tcl command that the script accesses the cursor methods. -
The options are as follows: -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_del.html b/bdb/docs/api_tcl/db_del.html deleted file mode 100644 index b3340312ab2..00000000000 --- a/bdb/docs/api_tcl/db_del.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - -
-
-db del- |
-
-
- |
db del - [-glob] - [-txn txnid] - key -
The db del command removes key/data pairs from the database. -
In the presence of duplicate key values, all records associated with the -designated key will be discarded. -
The options are as follows: -
The db del command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_get.html b/bdb/docs/api_tcl/db_get.html deleted file mode 100644 index 391f156529a..00000000000 --- a/bdb/docs/api_tcl/db_get.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - -
-
-db get- |
-
-
- |
db get
- [-consume]
- [-consume_wait]
- [-glob]
- [-partial {doff dlen}]
- [-recno]
- [-rmw]
- [-txn txnid]
- key
-db get
- -get_both
- [-partial {doff dlen}]
- [-rmw]
- [-txn txnid]
- key data
-The db get command returns key/data pairs from the database. -
In the presence of duplicate key values, db get will return all -duplicate items. Duplicates are sorted by insert order except where this -order has been overridden by cursor operations. -
The options are as follows: -
As the db get command will not hold locks across Berkeley DB interface -calls in non-transactional environments, the -rmw argument to the -db get call is only meaningful in the presence of transactions. -
If the underlying database is a Queue or Recno database, then the given -key will be interpreted by Tcl as an integer. For all other database -types, the key is interpreted by Tcl as a byte array unless indicated -by a given option. -
A list of key/data pairs is returned. In the error case that no matching -key exists, an empty list is returned. In all other cases, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_get_join.html b/bdb/docs/api_tcl/db_get_join.html deleted file mode 100644 index e2ede7e47d4..00000000000 --- a/bdb/docs/api_tcl/db_get_join.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - - -
-
-db get_join- |
-
-
- |
db get_join
- [-txn txnid]
- {db key}
- {db key}
- ...
-The db get_join command performs the cursor operations required to -join the specified keys and returns a list of joined {key data} pairs. -See Logical join for more information on -the underlying requirements for joining. -
The options are as follows: -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_get_type.html b/bdb/docs/api_tcl/db_get_type.html deleted file mode 100644 index 75fac1e78ae..00000000000 --- a/bdb/docs/api_tcl/db_get_type.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - - -
-
-db get_type- |
-
-
- |
db get_type -
The db get_type command returns the underlying database type, -returning one of "btree", "hash", "queue" or "recno". -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_is_byteswapped.html b/bdb/docs/api_tcl/db_is_byteswapped.html deleted file mode 100644 index 6a196eddf73..00000000000 --- a/bdb/docs/api_tcl/db_is_byteswapped.html +++ /dev/null @@ -1,37 +0,0 @@ - - - - - -
-
-db is_byteswapped- |
-
-
- |
db is_byteswapped -
The db is_byteswapped command returns 0 if the underlying database -files were created on an architecture of the same byte order as the -current one, and 1 if they were not (i.e., big-endian on a little-endian -machine or vice-versa). This value may be used to determine if application -data needs to be adjusted for this architecture or not. -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_join.html b/bdb/docs/api_tcl/db_join.html deleted file mode 100644 index ba3f0a2e5cb..00000000000 --- a/bdb/docs/api_tcl/db_join.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - -
-
-db join- |
-
-
- |
db join - db.cX - db.cY - db.cZ - ... -
The db join command joins the specified cursors and returns a -cursor handle that can be used to iterate through the joined {key data} -pairs. The returned cursor handle is bound to a Tcl command of the form -dbN.cX, where X is an integer starting at 0 (e.g., db0.c0 and -db0.c1). It is through this Tcl command that the script accesses the -cursor methods. -
The returned join cursor has limited cursor functionality and only the -dbc get and dbc close commands will succeed. -
See Logical join for more information on -the underlying requirements for joining. -
In a transaction protected environment, all of the cursors listed must -have been created within the same transaction. -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_open.html b/bdb/docs/api_tcl/db_open.html deleted file mode 100644 index 4f7b651e552..00000000000 --- a/bdb/docs/api_tcl/db_open.html +++ /dev/null @@ -1,300 +0,0 @@ - - - - - -
-
-berkdb open- |
-
-
- |
berkdb open
- [-btree | -hash | -recno | -queue | -unknown]
- [-cachesize {gbytes bytes ncache}]
- [-create]
- [-delim delim]
- [-dup]
- [-dupsort]
- [-env env]
- [-errfile filename]
- [-excl]
- [-extent size]
- [-ffactor density]
- [-len len]
- [-mode mode]
- [-nelem size]
- [-pad pad]
- [-pagesize pagesize]
- [-rdonly]
- [-recnum]
- [-renumber]
- [-snapshot]
- [-source file]
- [-truncate]
- [-upgrade]
- [--]
- [file [database]]
-The berkdb open command opens, and optionally creates, a database. -The returned database handle is bound to a Tcl command of the form -dbN, where N is an integer starting at 0 (e.g., db0 and db1). -It is through this Tcl command that the script accesses the database -methods. -
The options are as follows: -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
As databases opened within Berkeley DB environments use the cache specified to -the environment, it is an error to attempt to set a cache in a database -created within an environment. -
This byte is used for variable length records, if the -source -argument file is specified. If the -source argument file is -specified and no delimiting byte was specified, <newline> -characters (i.e. ASCII 0x0a) are interpreted as end-of-record markers. -
It is an error to specify both -dup and -recnum. -
If a -env argument is given, the database is created within the -specified Berkeley DB environment. The database access methods automatically -make calls to the other subsystems in Berkeley DB based on the enclosing -environment. For example, if the environment has been configured to use -locking, then the access methods will automatically acquire the correct -locks when reading and writing pages of the database. -
When an error occurs in the Berkeley DB library, a Berkeley DB error or an error -return value is returned by the function. In some cases, however, the -errno value may be insufficient to completely describe the cause of the -error especially during initial application debugging. -
The -errfile argument is used to enhance the mechanism for -reporting error messages to the application by specifying a file to be -used for displaying additional Berkeley DB error messages. In some cases, when -an error occurs, Berkeley DB will output an additional error message to the -specified file reference. -
The error message will consist of a Tcl command name and a colon (":"), -an error string, and a trailing <newline> character. If the -database was opened in an environment the Tcl command name will be the -environment name (e.g., env0), otherwise it will be the database command -name (e.g., db0). -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
For database handles opened inside of Berkeley DB environments, specifying the --errfile argument affects the entire environment and is equivalent -to specifying the same argument to the berkdb env command. -
For information on tuning the extent size, see -Selecting a extent size. -
The density is an approximation of the number of keys allowed to -accumulate in any one bucket -
For the Recno access method, specify that the records are fixed-length, -not byte delimited, and are of length len. -
Any records added to the database that are less than len bytes -long are automatically padded (see the -pad argument for more -information). -
Any attempt to insert records into the database that are greater than -len bytes long will cause the call to fail immediately and return -an error. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by the access methods -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
If not set or set too low, hash tables will still expand gracefully as -keys are entered, although a slight performance degradation may be -noticed. -
If no pad character is specified, <space> characters (i.e., -ASCII 0x20) are used for padding. -
For information on tuning the Berkeley DB page size, see -Selecting a page size. -
Logical record numbers in Btree databases are mutable in the face of -record insertion or deletion. See the -renumber argument for -further discussion. -
Maintaining record counts within a Btree introduces a serious point of -contention, namely the page locations where the record counts are stored. In -addition, the entire tree must be locked during both insertions and -deletions, effectively single-threading the tree for those operations. -Specifying -recnum can result in serious performance degradation -for some applications and data sets. -
It is an error to specify both -dup and -recnum. -
Using the db put or dbc put interfaces to create new records will -cause the creation of multiple records if the record number is more than one -greater than the largest record currently in the database. For example, -creating record 28, when record 25 was previously the last record in the -database, will create records 26 and 27 as well as 28. -
If a created record is not at the end of the database, all records following -the new record will be automatically renumbered upward by 1. For example, -the creation of a new record numbered 8 causes records numbered 8 and -greater to be renumbered upward by 1. If a cursor was positioned to record -number 8 or greater before the insertion, it will be shifted upward 1 -logical record, continuing to reference the same record as it did before. -
For these reasons, concurrent access to a Recno database with the --renumber flag specified may be largely meaningless, although it -is supported. -
If the -source argument is give, it specifies an underlying flat -text database file that is read to initialize a transient record number -index. In the case of variable length records, the records are separated -as specified by -delim. For example, standard UNIX byte stream -files can be interpreted as a sequence of variable length records -separated by <newline> characters. -
In addition, when cached data would normally be written back to the -underlying database file (e.g., the db close or db sync -commands are called), the in-memory copy of the database will be written -back to the -source file. -
By default, the backing source file is read lazily, i.e., records are not -read from the file until they are requested by the application. -If multiple processes (not threads) are accessing a Recno database -concurrently and either inserting or deleting records, the backing source -file must be read in its entirety before more than a single process -accesses the database, and only that process should specify the backing -source argument as part of the berkdb open call. See the -snapshot -argument for more information. -
Reading and writing the backing source file specified by -source -cannot be transactionally protected because it involves filesystem -operations that are not part of the Berkeley DB transaction methodology. -For this reason, if a temporary database is used to hold the records, -i.e., no file argument was specified to the berkdb open call, -it is possible to lose the contents of the -file file, e.g., if -the system crashes at the right instant. If a file is used to hold the -database, i.e., a file name was specified as the file argument -to berkdb open, normal database recovery on that file can be used to -prevent information loss, although it is still possible that the contents -of -source will be lost if the system crashes. -
The -source file must already exist (but may be zero-length) when -berkdb open is called. -
It is not an error to specify a read-only -source file when -creating a database, nor is it an error to modify the resulting database. -However, any attempt to write the changes to the backing source file using -either the db close or db sync commands will fail, of course. -Specify the -nosync argument to the db close command will -stop it from attempting to write the changes to the backing file, instead, -they will be silently discarded. -
For all of the above reasons, the -source file is generally used -to specify databases that are read-only for Berkeley DB applications, and that -are either generated on the fly by software tools, or modified using a -different mechanism, e.g., a text editor. -
The -truncate argument cannot be transaction protected, and it is -an error to specify it in a transaction protected environment. -
Note: Database upgrades are done in place and are -destructive, e.g., if pages need to be allocated and no disk space is -available, the database may be left corrupted. Backups should be made -before databases are upgraded. See Upgrading databases for more information. -
The berkdb open command returns a database handle on success. -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_put.html b/bdb/docs/api_tcl/db_put.html deleted file mode 100644 index 2311a3c97ac..00000000000 --- a/bdb/docs/api_tcl/db_put.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - -
-
-db put- |
-
-
- |
db put
- -append
- [-partial {doff dlen}]
- [-txn txnid]
- data
-db put
- [-nooverwrite]
- [-partial {doff dlen}]
- [-txn txnid]
- key data
-The db put command stores the specified key/data pair into the -database. -
The options are as follows: -
The dlen bytes starting doff bytes from the beginning of -the specified key's data record are replaced by the data specified by the -data and size structure elements. If dlen is smaller than the -length of the supplied data, the record will grow, and if dlen is -larger than the length of the supplied data, the record will shrink. If -the specified bytes do not exist, the record will be extended using nul -bytes as necessary, and the db put call will succeed. -
It is an error to attempt a partial put using the db put command in a database -that supports duplicate records. Partial puts in databases supporting -duplicate records must be done using a dbc put command. -
It is an error to attempt a partial put with differing dlen and -supplied data length values in Queue or Recno databases with fixed-length -records. -
The db put command returns either 0 or a record number for success -(the record number is returned if the -append option was specified). -If an error occurs, a Berkeley DB error message is returned or a Tcl error is -thrown. -
If the underlying database is a Queue or Recno database, then the given -key will be interpreted by Tcl as an integer. For all other database -types, the key is interpreted by Tcl as a byte array. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_remove.html b/bdb/docs/api_tcl/db_remove.html deleted file mode 100644 index e45f3bc4970..00000000000 --- a/bdb/docs/api_tcl/db_remove.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - -
-
-berkdb dbremove- |
-
-
- |
berkdb dbremove - [-env env] - [--] - file - [database] -
Remove the Berkeley DB database specified by the database name file and -[database] name arguments. If no database is specified, -the physical file represented by file is removed, incidentally -removing all databases that it contained. -
No reference count of database use is maintained by Berkeley DB. Applications -should not remove databases that are currently in use. -
The options are as follows: -
The berkdb dbremove command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_rename.html b/bdb/docs/api_tcl/db_rename.html deleted file mode 100644 index 75707d92a25..00000000000 --- a/bdb/docs/api_tcl/db_rename.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - -
-
-berkdb dbrename- |
-
-
- |
berkdb rename - [-env env] - [--] - file - [database - newname] -
Renames the Berkeley DB database specified by the database name file and -[database] name arguments to the new name given. -If no database is specified, -the physical file represented by file is renamed. -
No reference count of database use is maintained by Berkeley DB. Applications -should not rename databases that are currently in use. -
The options are as follows: -
The berkdb dbrename command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_stat.html b/bdb/docs/api_tcl/db_stat.html deleted file mode 100644 index 494226dfd31..00000000000 --- a/bdb/docs/api_tcl/db_stat.html +++ /dev/null @@ -1,41 +0,0 @@ - - - - - -
-
-db stat- |
-
-
- |
db stat - [-recordcount] -
The db stat command returns a list of name/value pairs comprising -the statistics of the database. -
The options are as follows: -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/db_sync.html b/bdb/docs/api_tcl/db_sync.html deleted file mode 100644 index f0e61b45a4d..00000000000 --- a/bdb/docs/api_tcl/db_sync.html +++ /dev/null @@ -1,36 +0,0 @@ - - - - - -
-
-db sync- |
-
-
- |
db sync -
The db sync command function flushes any database cached -information to disk. -
See db close for a discussion of Berkeley DB and cached data. -
The db sync command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/dbc_close.html b/bdb/docs/api_tcl/dbc_close.html deleted file mode 100644 index f3a63b4c559..00000000000 --- a/bdb/docs/api_tcl/dbc_close.html +++ /dev/null @@ -1,36 +0,0 @@ - - - - - -
-
-dbc close- |
-
-
- |
dbc close -
The dbc close command discards the cursor. -
Once dbc close has been called, regardless of its return, the -cursor handle may not be used again. -
The dbc close command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/dbc_del.html b/bdb/docs/api_tcl/dbc_del.html deleted file mode 100644 index 11264eeea09..00000000000 --- a/bdb/docs/api_tcl/dbc_del.html +++ /dev/null @@ -1,38 +0,0 @@ - - - - - -
-
-dbc del- |
-
-
- |
dbc del -
The dbc del command deletes the key/data pair currently referenced -by the cursor. -
The cursor position is unchanged after a delete, and subsequent calls to -cursor commands expecting the cursor to reference an existing key will -fail. -
The dbc del command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/dbc_dup.html b/bdb/docs/api_tcl/dbc_dup.html deleted file mode 100644 index 85b2bfb086e..00000000000 --- a/bdb/docs/api_tcl/dbc_dup.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - -
-
-dbc dup- |
-
-
- |
dbc dup - [-position] -
The dbc dup command duplicates the cursor, creates a new cursor -that uses the same transaction and locker ID as the original cursor. This -is useful when an application is using locking and requires two or more -cursors in the same thread of control. -
The options are as follows: -
The dbc dup command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/dbc_get.html b/bdb/docs/api_tcl/dbc_get.html deleted file mode 100644 index d16e51bdf9f..00000000000 --- a/bdb/docs/api_tcl/dbc_get.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - -
-
-dbc get- |
-
-
- |
dbc get
- [-current]
- [-first]
- [-get_recno]
- [-join_item]
- [-last]
- [-next]
- [-nextdup]
- [-nextnodup]
- [-partial {offset length}]
- [-prev]
- [-prevnodup]
- [-rmw]
-dbc get
- [-partial {offset length}]
- [-rmw]
- [-set]
- [-set_range]
- [-set_recno]
- key
-dbc get
- -get_both
- [-partial {offset length}]
- [-rmw]
- key data
-The dbc get command returns a list of {key value} pairs, except in -the case of the -get_recno and -join_item options. In -the case of the -get_recno option, dbc get returns a list -of the record number. In the case of the -join_item option, -dbc get returns a list containing the joined key. -
The options are as follows: -
If the cursor key/data pair was deleted, dbc get will return an -empty list. -
If the database is a Queue or Recno database, dbc get using the --first option will skip any keys that exist but were never -explicitly created by the application or were created and later deleted. -
If the database is empty, dbc get will return an empty list. -
If the database is a Queue or Recno database, dbc get using the --last option will skip any keys that exist but were never -explicitly created by the application or were created and later deleted. -
If the database is empty, dbc get will return an empty list. -
Otherwise, the cursor is moved to the next key/data pair of the database, -and that pair is returned. In the presence of duplicate key values, the -value of the key may not change. -
If the database is a Queue or Recno database, dbc get using the --next option will skip any keys that exist but were never -explicitly created by the application or were created and later deleted. -
If the cursor is already on the last record in the database, dbc get -will return an empty list. -
Otherwise, the cursor is moved to the next non-duplicate -key/data pair of the database, and that pair is returned. -
If no non-duplicate key/data pairs occur after the cursor -position in the database, dbc get will return an empty list. -
Otherwise, the cursor is moved to the previous key/data pair of the -database, and that pair is returned. In the presence of duplicate key -values, the value of the key may not change. -
If the database is a Queue or Recno database, dbc get using the --prev flag will skip any keys that exist but were never explicitly -created by the application or were created and later deleted. -
If the cursor is already on the first record in the database, -dbc get will return an empty list. -
Otherwise, the cursor is moved to the previous non-duplicate -key/data pair of the database, and that pair is returned. -
If no non-duplicate key/data pairs occur before the cursor -position in the database, dbc get will return an empty list. -
In the presence of duplicate key values, dbc get will return the -first data item for the given key. -
If the database is a Queue or Recno database and the requested key exists, -but was never explicitly created by the application or was later deleted, -dbc get will return an empty list. -
If no matching keys are found, dbc get will return an empty list. -
For -get_both to be specified, the underlying database must be of -type Btree or Hash. -
For the -set_recno option to be specified, the underlying database -must be of type Btree and it must have been created with the -recnum -option. -
For -get_recno to be specified, the underlying database must be -of type Btree and it must have been created with the -recnum -option. -
For -join_item to be specified, the cursor must have been created -by the db join command. -
If a key is specified, and -if the underlying database is a Queue or Recno database, then the given -key will be interpreted by Tcl as an integer. For all other database -types, the key is interpreted by Tcl as a byte array unless indicated -by a given option. -
In the normal error case of attempting to retrieve a key that does not -exist an empty list is returned. -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/dbc_put.html b/bdb/docs/api_tcl/dbc_put.html deleted file mode 100644 index bd791ab94d2..00000000000 --- a/bdb/docs/api_tcl/dbc_put.html +++ /dev/null @@ -1,133 +0,0 @@ - - - - - -
-
-dbc put- |
-
-
- |
dbc put
- [-after]
- [-before]
- [-current]
- [-partial {doff dlen}]
- data
-dbc put
- [-keyfirst]
- [-keylast]
- [-partial {doff dlen}]
- key data
-The dbc put command stores the specified key/data pair into the -database. -
The options are as follows: -
In the case of the Recno access method, it is an error to specify --after option if the underlying Recno database was not created -with the -renumber option. If the -renumber option was -specified, a new key is created, all records after the inserted item are -automatically renumbered, and the key of the new record is returned in -the structure referenced by the parameter key. The initial value of the -key parameter is ignored. See berkdb open for more information. -
In the case of the Queue access method, it is always an error to specify --after. -
If the current cursor record has already been deleted and the underlying -access method is Hash, dbc put will throw a Tcl error. If the -underlying access method is Btree or Recno, the operation will succeed. -
In the case of the Recno access method, it is an error to specify --before if the underlying Recno database was not created with the --before option. If the -before option was specified, a -new key is created, the current record and all records after it are -automatically renumbered, and the key of the new record is returned in -the structure referenced by the parameter key. The initial value of the -key parameter is ignored. See berkdb open for more information. -
In the case of the Queue access method, it is always an error to specify --before. -
If the current cursor record has already been deleted and the underlying -access method is Hash, dbc put will throw a Tcl error. If the -underlying access method is Btree or Recno, the operation will succeed. -
If the -dupsort option was specified to berkdb open and the -data item of the current referenced key/data pair does not compare -equally to the data parameter, dbc put will throw a Tcl error. -
If the current cursor record has already been deleted and the underlying -access method is Hash, dbc put will throw a Tcl error. If the -underlying access method is Btree, Queue or Recno, the operation will -succeed. -
If the key already exists in the database, and the -dupsort option -was specified to berkdb open, the inserted data item is added in its -sorted location. If the key already exists in the database, and the --dupsort option was not specified, the inserted data item is added -as the first of the data items for that key. -
The -keyfirst option may not be specified to the Queue or Recno -access methods. -
If the key already exists in the database, and the -dupsort option -was specified to berkdb open, the inserted data item is added in its -sorted location. If the key already exists in the database, and the --dupsort option was not specified, the inserted data item is added -as the last of the data items for that key. -
The -keylast option may not be specified to the Queue or Recno -access methods. -
The dlen bytes starting doff bytes from the beginning of -the specified key's data record are replaced by the data specified by the -data and size structure elements. If dlen is smaller than the -length of the supplied data, the record will grow, and if dlen is -larger than the length of the supplied data, the record will shrink. If -the specified bytes do not exist, the record will be extended using nul -bytes as necessary, and the dbc put call will succeed. -
It is an error to attempt a partial put using the dbc put command in a database -that supports duplicate records. Partial puts in databases supporting -duplicate records must be done using a dbc put command. -
It is an error to attempt a partial put with differing dlen and -supplied data length values in Queue or Recno databases with fixed-length -records. -
If a key is specified, and -if the underlying database is a Queue or Recno database, then the given -key will be interpreted by Tcl as an integer. For all other database -types, the key is interpreted by Tcl as a byte array. -
If dbc put fails for any reason, the state of the cursor will be -unchanged. If dbc put succeeds and an item is inserted into the -database, the cursor is always positioned to reference the newly inserted -item. -
The dbc put command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/env_close.html b/bdb/docs/api_tcl/env_close.html deleted file mode 100644 index 719ad2160ad..00000000000 --- a/bdb/docs/api_tcl/env_close.html +++ /dev/null @@ -1,42 +0,0 @@ - - - - - -
-
-env close- |
-
-
- |
env close -
Close the Berkeley DB environment, freeing any allocated resources and closing -any underlying subsystems. -
This does not imply closing any databases that were opened in the -environment. -
Where the environment was initialized with the -lock option, -calling env close does not release any locks still held by the -closing process, providing functionality for long-lived locks. -
Once env close has been called the env handle may not be -accessed again. -
The env close command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/env_open.html b/bdb/docs/api_tcl/env_open.html deleted file mode 100644 index 1c5bafee4b9..00000000000 --- a/bdb/docs/api_tcl/env_open.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - -
-
-berkdb env- |
-
-
- |
berkdb env
- [-cachesize {gbytes bytes ncache}]
- [-create]
- [-data_dir dirname]
- [-errfile filename]
- [-home directory]
- [-log_dir dirname]
- [-mode mode]
- [-private]
- [-recover]
- [-recover_fatal]
- [-shm_key shmid]
- [-system_mem]
- [-tmp_dir dirname]
- [-txn [nosync]]
- [-txn_max max]
- [-use_environ]
- [-use_environ_root]
-The berkdb env command opens, and optionally creates, a database -environment. The returned environment handle is bound to a Tcl command -of the form envN, where N is an integer starting at 0 (e.g., env0 -and env1). It is through this Tcl command that the script accesses the -environment methods. -The command automatically initializes the shared memory buffer pool subsystem. -This subsystem is used whenever the application is -using any Berkeley DB access method. -
The options are as follows: -
The default cache size is 256KB, and may not be specified as less than -20KB. Any cache size less than 500MB is automatically increased by 25% -to account for buffer pool overhead, cache sizes larger than 500MB are -used as specified. -
It is possible to specify caches to Berkeley DB that are large enough so that -they cannot be allocated contiguously on some architectures, e.g., some -releases of Solaris limit the amount of memory that may be allocated -contiguously by a process. If ncache is 0 or 1, the cache will -be allocated contiguously in memory. If it is greater than 1, the cache -will be broken up into ncache equally sized separate pieces of -memory. -
For information on tuning the Berkeley DB cache size, see -Selecting a cache size. -
When an error occurs in the Berkeley DB library, a Berkeley DB error or an error -return value is returned by the function. In some cases, however, the -errno value may be insufficient to completely describe the cause of the -error especially during initial application debugging. -
The -errfile argument is used to enhance the mechanism for -reporting error messages to the application by specifying a file to be -used for displaying additional Berkeley DB error messages. In some cases, when -an error occurs, Berkeley DB will output an additional error message to the -specified file reference. -
The error message will consist of the environment command name (e.g., env0) -and a colon (":"), an error string, and a trailing <newline> -character. -
This error logging enhancement does not slow performance or significantly -increase application size, and may be run during normal operation as well -as during application debugging. -
On UNIX systems, or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by Berkeley DB -are created with mode mode (as described in chmod(2)) and -modified by the process' umask value at the time of creation (see -umask(2)). The group ownership of created files is based on -the system and directory defaults, and is not further specified by Berkeley DB. -If mode is 0, files are created readable and writeable by both -owner and group. On Windows systems, the mode argument is ignored. -
This flag should not be specified if more than a single process is -accessing the environment, as it is likely to cause database corruption -and unpredictable behavior, e.g., if both a server application and the -Berkeley DB utility db_stat will access the environment, the --private option should not be specified. -
If the optional nosync argument is specified, the log will not be -synchronously flushed on transaction commit or prepare. This means that -transactions exhibit the ACI (atomicity, consistency and isolation) -properties, but not D (durability), i.e., database integrity will be -maintained but it is possible that some number of the most recently -committed transactions may be undone during recovery instead of being -redone. -
The number of transactions that are potentially at risk is governed by -how often the log is checkpointed (see db_checkpoint for more -information) and how many log updates can fit on a single log page. -
The berkdb env command returns an environment handle on success. -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/env_remove.html b/bdb/docs/api_tcl/env_remove.html deleted file mode 100644 index ca90595f83a..00000000000 --- a/bdb/docs/api_tcl/env_remove.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - - -
-
-berkdb envremove- |
-
-
- |
berkdb envremove - [-data_dir directory] - [-force] - [-home directory] - [-log_dir directory] - [-tmp_dir directory] - [-use_environ] - [-use_environ_root] -
Remove a Berkeley DB environment. -
The options are as follows: -
The berkdb envremove command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/pindex.src b/bdb/docs/api_tcl/pindex.src deleted file mode 100644 index 668f53d25f8..00000000000 --- a/bdb/docs/api_tcl/pindex.src +++ /dev/null @@ -1,27 +0,0 @@ -__APIREL__/api_tcl/db_close.html#2 @db close -__APIREL__/api_tcl/db_count.html#2 @db count -__APIREL__/api_tcl/db_cursor.html#2 @db cursor -__APIREL__/api_tcl/db_del.html#2 @db del -__APIREL__/api_tcl/db_get.html#2 @db get -__APIREL__/api_tcl/db_get_join.html#2 @db get_join -__APIREL__/api_tcl/db_get_type.html#2 @db get_type -__APIREL__/api_tcl/db_is_byteswapped.html#2 @db is_byteswapped -__APIREL__/api_tcl/db_join.html#2 @db join -__APIREL__/api_tcl/db_open.html#2 @berkdb open -__APIREL__/api_tcl/db_put.html#2 @db put -__APIREL__/api_tcl/db_rename.html#2 @berkdb dbrename -__APIREL__/api_tcl/db_remove.html#2 @berkdb dbremove -__APIREL__/api_tcl/db_stat.html#2 @db stat -__APIREL__/api_tcl/db_sync.html#2 @db sync -__APIREL__/api_tcl/dbc_close.html#2 @db close -__APIREL__/api_tcl/dbc_del.html#2 @db del -__APIREL__/api_tcl/dbc_dup.html#2 @db dup -__APIREL__/api_tcl/dbc_get.html#2 @db get -__APIREL__/api_tcl/dbc_put.html#2 @dbc put -__APIREL__/api_tcl/env_close.html#2 @env close -__APIREL__/api_tcl/env_open.html#2 @berkdb env -__APIREL__/api_tcl/env_remove.html#2 @berkdb envremove -__APIREL__/api_tcl/txn.html#2 @env txn -__APIREL__/api_tcl/txn_abort.html#2 @txn abort -__APIREL__/api_tcl/txn_commit.html#2 @txn commit -__APIREL__/api_tcl/version.html#2 @berkdb version diff --git a/bdb/docs/api_tcl/tcl_index.html b/bdb/docs/api_tcl/tcl_index.html deleted file mode 100644 index a31c6fc82a1..00000000000 --- a/bdb/docs/api_tcl/tcl_index.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - -
-| Tcl Command | Description |
|---|---|
| berkdb dbremove | Remove a database |
| berkdb dbrename | Rename a database |
| berkdb env | Create an environment handle |
| berkdb envremove | Remove an environment |
| berkdb open | Create a database handle |
| berkdb version | Return version information |
| env close | Close an environment |
| env txn | Begin a transaction |
| db close | Close a database |
| db count | Return a count of a key's data items |
| db cursor | Open a cursor into a database |
| db del | Delete items from a database |
| db get | Get items from a database |
| db get_join | Get items from a database join |
| db get_type | Return the database type |
| db is_byteswapped | Return if the underlying database is in host order |
| db join | Perform a database join on cursors |
| db put | Store items into a database |
| db stat | Return database statistics |
| db sync | Flush a database to stable storage |
| dbc close | Close a cursor |
| dbc del | Delete by cursor |
| dbc dup | Duplicate a cursor |
| dbc get | Retrieve by cursor |
| dbc put | Store by cursor |
| txn abort | Abort a transaction |
| txn commit | Commit a transaction |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/tcl_pindex.html b/bdb/docs/api_tcl/tcl_pindex.html deleted file mode 100644 index c82153bad43..00000000000 --- a/bdb/docs/api_tcl/tcl_pindex.html +++ /dev/null @@ -1,258 +0,0 @@ - -
-| configuring Berkeley DB | 1.85 API compatibility |
| building a utility to dump Berkeley DB | 1.85 databases |
| Upgrading to release | 2.0 |
| Upgrading to release | 3.0 |
| Upgrading to release | 3.1 |
| Upgrading to release | 3.2 |
| selecting an | access method |
| access methods | |
| AIX | |
| programmatic | APIs |
| utility to | archive log files |
| berkdb dbremove | |
| berkdb dbrename | |
| berkdb env | |
| berkdb envremove | |
| berkdb open | |
| berkdb version | |
| berkeley_db_svc | |
| building for UNIX | |
| building for UNIX FAQ | |
| building for VxWorks | |
| building for VxWorks FAQ | |
| building for Win32 | |
| building for Windows FAQ | |
| selecting a | byte order |
| byte ordering | |
| configuring the | C++ API |
| flushing the database | cache |
| selecting a | cache size |
| catastrophic recovery | |
| Patches, Updates and | Change logs |
| utility to take | checkpoints |
| closing a cursor | |
| closing a database | |
| specifying a Btree | comparison function |
| changing | compile or load options |
| Concurrent Data Store | |
| configuring Berkeley DB for UNIX systems | |
| recovering | corrupted databases |
| counting data items for a key | |
| closing a | cursor |
| deleting records with a | cursor |
| duplicating a | cursor |
| retrieving records with a | cursor |
| storing records with a | cursor |
| cursor stability | |
| database | cursors |
| utility to upgrade | database files |
| utility to verify | database files |
| db close | |
| db close | |
| db count | |
| db cursor | |
| db del | |
| db del | |
| db dup | |
| db get | |
| db get | |
| db get_join | |
| db get_type | |
| db is_byteswapped | |
| db join | |
| db put | |
| db stat | |
| db sync | |
| db_archive | |
| dbc put | |
| db_checkpoint | |
| File naming | DB_CONFIG |
| db_deadlock | |
| db_dump | |
| File naming | DB_HOME |
| File naming | db_home |
| Error returns to applications | DB_KEYEMPTY |
| db_load | |
| Error returns to applications | DB_LOCK_DEADLOCK |
| Error returns to applications | DB_LOCK_NOTGRANTED |
| Error returns to applications | DB_NOTFOUND |
| db_printlog | |
| db_recover | |
| Error returns to applications | DB_RUNRECOVERY |
| db_stat | |
| db_upgrade | |
| db_verify | |
| deadlocks | |
| utility to detect | deadlocks |
| debugging applications | |
| deleting records | |
| deleting records with a cursor | |
| Configuring Berkeley DB | --disable-bigfile |
| disk space requirements | |
| utility to | dump databases as text files |
| duplicate data items | |
| duplicating a cursor | |
| configuring | dynamic shared libraries |
| Configuring Berkeley DB | --enable-compat185 |
| Configuring Berkeley DB | --enable-cxx |
| Configuring Berkeley DB | --enable-debug |
| Configuring Berkeley DB | --enable-debug_rop |
| Configuring Berkeley DB | --enable-debug_wop |
| Configuring Berkeley DB | --enable-diagnostic |
| Configuring Berkeley DB | --enable-dump185 |
| Configuring Berkeley DB | --enable-dynamic |
| Configuring Berkeley DB | --enable-java |
| Configuring Berkeley DB | --enable-posixmutexes |
| Configuring Berkeley DB | --enable-rpc |
| Configuring Berkeley DB | --enable-shared |
| Configuring Berkeley DB | --enable-tcl |
| Configuring Berkeley DB | --enable-test |
| Configuring Berkeley DB | --enable-uimutexes |
| Configuring Berkeley DB | --enable-umrw |
| byte | endian |
| env close | |
| env txn | |
| database | environment |
| environment variables | |
| error handling | |
| error name space | |
| error returns | |
| /etc/magic | |
| selecting a Queue | extent size |
| Java | FAQ |
| Tcl | FAQ |
| configuring without large | file support |
| file utility | |
| recovery and | filesystem operations |
| remote | filesystems |
| page | fill factor |
| FreeBSD | |
| Berkeley DB | free-threaded handles |
| specifying a database | hash |
| hash table size | |
| HP-UX | |
| installing Berkeley DB for UNIX systems | |
| interface compatibility | |
| IRIX | |
| configuring the | Java API |
| Java compatibility | |
| Java configuration | |
| Java FAQ | |
| logical | join |
| database | limits |
| Linux | |
| changing compile or | load options |
| utility to | load text files into databases |
| standard | lock modes |
| page-level | locking |
| two-phase | locking |
| locking and non-Berkeley DB applications | |
| locking configuration | |
| locking conventions | |
| Berkeley DB Concurrent Data Store | locking conventions |
| locking introduction | |
| sizing the | locking subsystem |
| locking without transactions | |
| log file limits | |
| log file removal | |
| utility to display | log files as text |
| logging configuration | |
| logging introduction | |
| memory pool configuration | |
| Berkeley DB library | name spaces |
| file | naming |
| retrieving Btree records by | number |
| opening a database | |
| OSF/1 | |
| selecting a | page size |
| partial record storage and retrieval | |
| Patches, Updates and Change logs | |
| Perl | |
| Sleepycat Software's Berkeley DB | products |
| QNX | |
| logical | record numbers |
| managing | record-based databases |
| logically renumbering | records |
| utility to | recover database environments |
| Berkeley DB | recoverability |
| retrieving records | |
| retrieving records with a cursor | |
| RPC client | |
| configuring a | RPC client/server |
| utility to support | RPC client/server |
| RPC server | |
| database | salvage |
| SCO | |
| Berkeley DB handle | scope |
| security | |
| Sendmail | |
| configuring | shared libraries |
| shared libraries | |
| application | signal handling |
| Sleepycat Software | |
| Solaris | |
| source code layout | |
| cursor | stability |
| database | statistics |
| utility to display database and environment | statistics |
| storing records | |
| storing records with a cursor | |
| SunOS | |
| loading Berkeley DB with | Tcl |
| using Berkeley DB with | Tcl |
| configuring the | Tcl API |
| Tcl API programming notes | |
| Tcl FAQ | |
| configuring the | test suite |
| running the | test suite |
| running the | test suite under UNIX |
| running the | test suite under Windows |
| text backing files | |
| loading | text into databases |
| dumping/loading | text to/from databases |
| building | threaded applications |
| transaction configuration | |
| transaction limits | |
| administering | transaction protected applications |
| archival in | transaction protected applications |
| checkpoints in | transaction protected applications |
| deadlock detection in | transaction protected applications |
| recovery in | transaction protected applications |
| transaction throughput | |
| Transactional Data Store | |
| Berkeley DB and | transactions |
| nested | transactions |
| configuring Berkeley DB with the | Tuxedo System |
| txn abort | |
| txn commit | |
| Ultrix | |
| building for | UNIX FAQ |
| configuring Berkeley DB for | UNIX systems |
| Patches, | Updates and Change logs |
| utility to | upgrade database files |
| upgrading databases | |
| utilities | |
| database | verification |
| utility to | verify database files |
| building for | VxWorks FAQ |
| VxWorks notes | |
| running the test suite under | Windows |
| building for | Windows FAQ |
| Windows notes | |
| Configuring Berkeley DB | --with-tcl=DIR |
| XA Resource Manager |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/txn.html b/bdb/docs/api_tcl/txn.html deleted file mode 100644 index 4e66a96a6ae..00000000000 --- a/bdb/docs/api_tcl/txn.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - - -
-
-env txn- |
-
-
- |
env txn - [-nosync] - [-nowait] - [-parent txnid] - [-sync] -
The env txn command begins a transaction. The returned transaction -handle is bound to a Tcl command of the form env.txnX, where X -is an integer starting at 0 (e.g., env0.txn0 and env0.txn1). It is -through this Tcl command that the script accesses the transaction methods. -
The options are as follows: -
This behavior may be set for an entire Berkeley DB environment as part of -the berkdb env interface. -
This behavior is the default for Berkeley DB environments unless the --nosync option was specified to the berkdb env interface. -
The env txn command returns a transaction handle on success. -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/txn_abort.html b/bdb/docs/api_tcl/txn_abort.html deleted file mode 100644 index 8b147883f6d..00000000000 --- a/bdb/docs/api_tcl/txn_abort.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - - -
-
-txn abort- |
-
-
- |
txn abort -
The txn abort command causes an abnormal termination of the -transaction. -
The log is played backwards and any necessary recovery operations are -performed. After recovery is completed, all locks held by the -transaction are acquired by the parent transaction in the case of a -nested transaction or released in the case of a non-nested transaction. -As is the case for txn commit, applications that require strict -two-phase locking should not explicitly release any locks. -
In the case of nested transactions, aborting the parent transaction -causes all children of that transaction to be aborted. -
Once txn abort has been called, regardless of its return, the -txn handle may not be accessed again. -
The txn abort command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/txn_commit.html b/bdb/docs/api_tcl/txn_commit.html deleted file mode 100644 index acd1f2d1b29..00000000000 --- a/bdb/docs/api_tcl/txn_commit.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - -
-
-txn commit- |
-
-
- |
txn commit - [-nosync] - [-sync] -
The txn commit command ends the transaction. -
In the case of nested transactions, if the transaction is a parent -transaction with unresolved (neither committed or aborted) child -transactions, the child transactions are aborted and the commit of the -parent will succeed. -
In the case of nested transactions, if the transaction is a child -transaction, its locks are not released, but are acquired by its parent. -While the commit of the child transaction will succeed, the actual -resolution of the child transaction is postponed until the parent -transaction is committed or aborted, i.e., if its parent transaction -commits, it will be committed, and if its parent transaction aborts, it -will be aborted. -
If the -nosync option is not specified, a commit log record is -written and flushed to disk, as are all previously written log records. -
The options are as follows: -
This behavior may be set for an entire Berkeley DB environment as part of -the berkdb env interface. -
This behavior is the default for Berkeley DB environments unless the --nosync option was specified to the berkdb env or -env txn interfaces. -
Once txn commit has been called, regardless of its return, the -txn handle may not be accessed again. If txn commit -encounters an error, then this transaction and all child transactions -of this transaction are aborted. -
The txn commit command returns 0 on success, and in the case of error, a Tcl error -is thrown. - -
|
-
- |
Copyright Sleepycat Software - - diff --git a/bdb/docs/api_tcl/version.html b/bdb/docs/api_tcl/version.html deleted file mode 100644 index ab4b901f1e9..00000000000 --- a/bdb/docs/api_tcl/version.html +++ /dev/null @@ -1,39 +0,0 @@ - - - - - -
-
-berkdb version- |
-
-
- |
berkdb version - [-string] -
Return a list of the form {major minor patch} for the major, minor and -patch levels of the underlying Berkeley DB release. -
The options are as follows: -
In the case of error, a Tcl error is thrown. - -
|
-
- |
Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/images/api.gif b/bdb/docs/images/api.gif
deleted file mode 100644
index dafd5772a14b391e7028eea4d1a2b659fdc1e640..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 121
zcmV-<0EYiZNk%v~VI%+~0Du4h`26?)001li0000a03-ka0$7BPsmtvTqhz7li?gP>
zdpm{VD1GL(oGM7R?hC(b)y_eT=b~ND`VR~WhoRdc17MMi$K#DTdLp3GT5{^VE}I5S
bx2J@Dw_`0fnlOsZld#vhCd%jZM*#pkQlT{?
diff --git a/bdb/docs/images/next.gif b/bdb/docs/images/next.gif
deleted file mode 100644
index 667ee061a9fe32e0a301dc255a41f85376506d86..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 225
zcmZ?wbh9u|RAEqIIK;s4
-
-... the embedded database companytm
-
-
-
- C++ API
- Java API
- Tcl API
- Building for Win32 platforms
-
- The DB->close function is the standard interface for closing the database.
-By default, DB->close also flushes all modified records from the
-database cache to disk.
- There is one flag that you can set to customize DB->close:
- While unlikely, it is possible for database corruption to happen if a
-system or application crash occurs while writing data to the database. To
-ensure that database corruption never occurs, applications must either:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/count.html b/bdb/docs/ref/am/count.html
deleted file mode 100644
index 92282641b6b..00000000000
--- a/bdb/docs/ref/am/count.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- Once a cursor has been initialized to reference a particular key in the
-database, it can be used to determine the number of data items that are
-stored for any particular key. The DBcursor->c_count method returns
-this number of data items. The returned value is always one, unless
-the database supports duplicate data items, in which case it may be any
-number of items.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/curclose.html b/bdb/docs/ref/am/curclose.html
deleted file mode 100644
index 52ccfeb8cd5..00000000000
--- a/bdb/docs/ref/am/curclose.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- The DBcursor->c_close function is the standard interface for closing a cursor,
-after which the cursor may no longer be used. Although cursors are
-implicitly closed when the database they point to are closed, it is good
-programming practice to explicitly close cursors. In addition, in
-transactional systems, cursors may not exist outside of a transaction and
-so must be explicitly closed.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/curdel.html b/bdb/docs/ref/am/curdel.html
deleted file mode 100644
index b0fe8f9573f..00000000000
--- a/bdb/docs/ref/am/curdel.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
- The DBcursor->c_del function is the standard interface for deleting records from
-the database using a cursor. The DBcursor->c_del function deletes the record
-currently referenced by the cursor. In all cases, the cursor position is
-unchanged after a delete.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/curdup.html b/bdb/docs/ref/am/curdup.html
deleted file mode 100644
index 6c609b2e545..00000000000
--- a/bdb/docs/ref/am/curdup.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- Once a cursor has been initialized (e.g., by a call to DBcursor->c_get),
-it can be thought of as identifying a particular location in a database.
-The DBcursor->c_dup function permits an application to create a new cursor that
-has the same locking and transactional information as the cursor from
-which it is copied, and which optionally refers to the same position in
-the database.
- In order to maintain a cursor position when an application is using
-locking, locks are maintained on behalf of the cursor until the cursor is
-closed. In cases when an application is using locking without
-transactions, cursor duplication is often required to avoid
-self-deadlocks. For further details, refer to
-Access method locking conventions.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/curget.html b/bdb/docs/ref/am/curget.html
deleted file mode 100644
index 129fa272bbd..00000000000
--- a/bdb/docs/ref/am/curget.html
+++ /dev/null
@@ -1,74 +0,0 @@
-
-
-
-
-
- The DBcursor->c_get function is the standard interface for retrieving records from
-the database with a cursor. The DBcursor->c_get function takes a flag which
-controls how the cursor is positioned within the database and returns the
-key/data item associated with that positioning. Similar to
-DB->get, DBcursor->c_get may also take a supplied key and retrieve
-the data associated with that key from the database. There are several
-flags that you can set to customize retrieval.
- In all cases, the cursor is repositioned by a DBcursor->c_get operation
-to point to the newly-returned key/data pair in the database.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/curput.html b/bdb/docs/ref/am/curput.html
deleted file mode 100644
index 0d5ef2725af..00000000000
--- a/bdb/docs/ref/am/curput.html
+++ /dev/null
@@ -1,40 +0,0 @@
-
-
-
-
-
- The DBcursor->c_put function is the standard interface for storing records into
-the database with a cursor. In general, DBcursor->c_put takes a key and
-inserts the associated data into the database, at a location controlled
-by a specified flag.
- There are several flags that you can set to customize storage:
- In all cases, the cursor is repositioned by a DBcursor->c_put operation
-to point to the newly inserted key/data pair in the database.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/cursor.html b/bdb/docs/ref/am/cursor.html
deleted file mode 100644
index 529285b4a78..00000000000
--- a/bdb/docs/ref/am/cursor.html
+++ /dev/null
@@ -1,41 +0,0 @@
-
-
-
-
-
- A database cursor is a reference to a single key/data pair in the
-database. It supports traversal of the database and is the only way to
-access individual duplicate data items. Cursors are used for operating
-on collections of records, for iterating over a database, and for saving
-handles to individual records, so that they can be modified after they
-have been read.
- The DB->cursor function is the standard interface for opening a cursor
-into a database. Upon return the cursor is uninitialized, positioning
-occurs as part of the first cursor operation.
- Once a database cursor has been opened, there are a set of access method
-operations that can be performed. Each of these operations is performed
-using a method referenced from the returned cursor handle.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/delete.html b/bdb/docs/ref/am/delete.html
deleted file mode 100644
index 8ab612fa428..00000000000
--- a/bdb/docs/ref/am/delete.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- The DB->del function is the standard interface for deleting records from
-the database. In general, DB->del takes a key and deletes the
-data item associated with it from the database.
- If the database has been configured to support duplicate records, the
-DB->del function will remove all of the duplicate records. To remove
-individual duplicate records, you must use a Berkeley DB cursor interface.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/error.html b/bdb/docs/ref/am/error.html
deleted file mode 100644
index 737e6d66217..00000000000
--- a/bdb/docs/ref/am/error.html
+++ /dev/null
@@ -1,61 +0,0 @@
-
-
-
-
-
- Berkeley DB offers programmatic support for displaying error return values.
- The db_strerror interface returns a pointer to the error
-message corresponding to any Berkeley DB error return, similar to the ANSI C
-strerror interface, but is able to handle both system error returns and
-Berkeley DB specific return values.
- For example:
- There are also two additional error interfaces, DB->err and
-DB->errx. These interfaces work like the ANSI C X3.159-1989 (ANSI C) printf
-interface, taking a printf-style format string and argument list, and
-writing a message constructed from the format string and arguments.
- The DB->err function appends the standard error string to the constructed
-message, the DB->errx function does not. These interfaces provide simpler
-ways of displaying Berkeley DB error messages. For example, if your application
-tracks session IDs in a variable called session_id, it can include that
-information in its error messages:
- Error messages can additionally be configured to always include a prefix
-(e.g., the program name) using the DB->set_errpfx interface.
- For example, if the program was called my_app, and the open call returned
-an EACCESS system error, the error messages shown would appear as follows:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/get.html b/bdb/docs/ref/am/get.html
deleted file mode 100644
index fda7a8eb2e6..00000000000
--- a/bdb/docs/ref/am/get.html
+++ /dev/null
@@ -1,39 +0,0 @@
-
-
-
-
-
- The DB->get function is the standard interface for retrieving records from
-the database. In general, DB->get takes a key and returns the
-associated data from the database.
- There are a few flags that you can set to customize retrieval:
- If the database has been configured to support duplicate records,
-DB->get will always return the first data item in the duplicate
-set.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/join.html b/bdb/docs/ref/am/join.html
deleted file mode 100644
index 9d4dcdd0949..00000000000
--- a/bdb/docs/ref/am/join.html
+++ /dev/null
@@ -1,184 +0,0 @@
-
-
-
-
-
- A logical join is a method of retrieving data from a primary database
-using criteria stored in a set of secondary indexes. A logical join
-requires that your data be organized as a primary database which
-contains the primary key and primary data field, and a set of secondary
-indexes. Each of the secondary indexes is indexed by a different
-secondary key, and, for each key in a secondary index, there is a set
-of duplicate data items that match the primary keys in the primary
-database.
- For example, let's assume the need for an application that will return
-the names of stores in which one can buy fruit of a given color. We
-would first construct a primary database that lists types of fruit as
-the key item, and the store where you can buy them as the data item:
- We would then create a secondary index with the key color, and,
-as the data items, the names of fruits of different colors.
- This secondary index would allow an application to look up a color, and
-then use the data items to look up the stores where the colored fruit
-could be purchased. For example, by first looking up blue,
-the data item blueberry could be used as the lookup key in the
-primary database, returning Farmer's Market.
- Your data must be organized in the following manner in order to use the
-DB->join function:
- These duplicate entries should be sorted for performance reasons, although
-it is not required. For more information see the DB_DUPSORT flag
-to the DB->set_flags function.
- What the DB->join function does is review a list of secondary keys, and,
-when it finds a data item that appears as a data item for all of the
-secondary keys, it uses that data items as a lookup into the primary
-database, and returns the associated data item.
- If there were a another secondary index that had as its key the
-cost of the fruit, a similar lookup could be done on stores
-where inexpensive fruit could be purchased:
- The DB->join function provides logical join functionality. While not
-strictly cursor functionality, in that it is not a method off a cursor
-handle, it is more closely related to the cursor operations than to the
-standard DB operations.
- It is also possible to do lookups based on multiple criteria in a single
-operation, e.g., it is possible to look up fruits that are both red and
-expensive in a single operation. If the same fruit appeared as a data
-item in both the color and expense indexes, then that fruit name would
-be used as the key for retrieval from the primary index, and would then
-return the store where expensive, red fruit could be purchased.
- Consider the following three databases:
- Consider the following query:
- This query finds are all the records in the primary database (personnel)
-for whom the criteria lastname=smith and job title=manager is
-true.
- Assume that all databases have been properly opened and have the handles:
-pers_db, name_db, job_db. We also assume that we have an active
-transaction referenced by the handle txn.
-
-name_curs = NULL;
-job_curs = NULL;
-memset(&key, 0, sizeof(key));
-memset(&data, 0, sizeof(data));
-
-if ((ret =
- name_db->cursor(name_db, txn, &name_curs)) != 0)
- goto err;
-key.data = "smith";
-key.size = sizeof("smith");
-if ((ret =
- name_curs->c_get(name_curs, &key, &data, DB_SET)) != 0)
- goto err;
-
-if ((ret = job_db->cursor(job_db, txn, &job_curs)) != 0)
- goto err;
-key.data = "manager";
-key.size = sizeof("manager");
-if ((ret =
- job_curs->c_get(job_curs, &key, &data, DB_SET)) != 0)
- goto err;
-
-carray[0] = name_curs;
-carray[1] = job_curs;
-carray[2] = NULL;
-
-if ((ret =
- pers_db->join(pers_db, carray, &join_curs, 0)) != 0)
- goto err;
-while ((ret =
- join_curs->c_get(join_curs, &key, &data, 0)) == 0) {
- /* Process record returned in key/data. */
-}
-
-/*
- * If we exited the loop because we ran out of records,
- * then it has completed successfully.
- */
-if (ret == DB_NOTFOUND)
- ret = 0;
-
-err:
-if (join_curs != NULL &&
- (tret = join_curs->c_close(join_curs)) != 0 && ret == 0)
- ret = tret;
-if (name_curs != NULL &&
- (tret = name_curs->c_close(name_curs)) != 0 && ret == 0)
- ret = tret;
-if (job_curs != NULL &&
- (tret = job_curs->c_close(job_curs)) != 0 && ret == 0)
- ret = tret;
-
-return (ret);
- The name cursor is positioned at the beginning of the duplicate list
-for smith and the job cursor is placed at the beginning of
-the duplicate list for manager. The join cursor is returned
-from the logical join call. This code then loops over the join cursor
-getting the personnel records of each one until there are no more.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/open.html b/bdb/docs/ref/am/open.html
deleted file mode 100644
index 01c45339ed8..00000000000
--- a/bdb/docs/ref/am/open.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
-
- The DB->open function is the standard interface for opening a database,
-and takes five arguments:
- There are a few flags that you can set to customize open:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/opensub.html b/bdb/docs/ref/am/opensub.html
deleted file mode 100644
index 066ca4b7933..00000000000
--- a/bdb/docs/ref/am/opensub.html
+++ /dev/null
@@ -1,64 +0,0 @@
-
-
-
-
-
- Applications may create multiple databases within a single physical
-file. This is useful when the databases are both numerous and
-reasonably small, in order to avoid creating a large number of
-underlying files, or when it is desirable to include secondary index
-databases in the same file as the primary index database. Multiple
-databases are an administrative convenience and using them is unlikely
-to effect database performance. To open or create a file that will
-include more than a single database, specify a database name when
-calling the DB->open method.
- Physical files do not need to be comprised of a single type of database,
-and databases in a file may be of any type (e.g., Btree, Hash or Recno),
-except for Queue databases. Queue databases must be created one per file
-and cannot share a file with any other database type. There is no limit
-on the number of databases that may be created in a single file other than
-the standard Berkeley DB file size and disk space limitations.
- It is an error to attempt to open a second database in a file that was
-not initially created using a database name, that is, the file must
-initially be specified as capable of containing multiple databases for a
-second database to be created in it.
- It is not an error to open a file that contains multiple databases without
-specifying a database name, however the database type should be specified
-as DB_UNKNOWN and the database must be opened read-only. The handle that
-is returned from such a call is a handle on a database whose key values
-are the names of the databases stored in the database file and whose data
-values are opaque objects. No keys or data values may be modified or
-stored using this database handle.
- Storing multiple databases in a single file is almost identical to
-storing each database in its own separate file. The one crucial
-difference is how locking and the underlying memory pool services must
-to be configured. As an example, consider two databases instantiated
-in two different physical files. If access to each separate database
-is single-threaded, there is no reason to perform any locking of any
-kind, and the two databases may be read and written simultaneously.
-Further, there would be no requirement to create a shared database
-environment in which to open the databases. Because multiple databases
-in a file exist in a single physical file, opening two databases in the
-same file requires that locking be enabled, unless access to the
-databases is known to be single-threaded, that is, only one of the
-databases is ever accessed at a time. (As the locks for the two
-databases can only conflict during page allocation, this additional
-locking is unlikely to effect performance.) Further, the databases must
-share an underlying memory pool so that per-physical-file information
-is updated correctly.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/ops.html b/bdb/docs/ref/am/ops.html
deleted file mode 100644
index 5daaddd7496..00000000000
--- a/bdb/docs/ref/am/ops.html
+++ /dev/null
@@ -1,36 +0,0 @@
-
-
-
-
-
- Once a database handle has been created using db_create, there
-are several standard access method operations. Each of these operations
-is performed using a method that is referenced from the returned handle.
-The operations are as follows:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/partial.html b/bdb/docs/ref/am/partial.html
deleted file mode 100644
index 7f3af8f68df..00000000000
--- a/bdb/docs/ref/am/partial.html
+++ /dev/null
@@ -1,134 +0,0 @@
-
-
-
-
-
- It is possible to both store and retrieve parts of data items in all
-Berkeley DB access methods. This is done by setting the
-DB_DBT_PARTIAL flag in the DBT structure passed to the
-Berkeley DB interface.
- The DB_DBT_PARTIAL flag is based on the values of two fields
-of the DBT structure, dlen and doff. The value
-of dlen is the number of bytes of the record in which the
-application is interested. The value of doff is the offset from
-the beginning of the data item where those bytes start.
- For example, if the data item were ABCDEFGHIJKL, a doff
-value of 3 would indicate that the bytes of interest started at
-D, and a dlen value of 4 would indicate that the bytes
-of interest were DEFG.
- When retrieving a data item from a database, the dlen bytes
-starting doff bytes from the beginning of the record are
-returned, as if they comprised the entire record. If any or all of the
-specified bytes do not exist in the record, the retrieval is still
-successful and any existing bytes (and nul bytes for any non-existent
-bytes) are returned.
- When storing a data item into the database, the dlen bytes
-starting doff bytes from the beginning of the specified key's
-data record are replaced by the data specified by the data and
-size fields. If dlen is smaller than size, the
-record will grow, and if dlen is larger than size, the
-record will shrink. If the specified bytes do not exist, the record will
-be extended using nul bytes as necessary, and the store call will still
-succeed.
- The following are various examples of the put case for the
-DB_DBT_PARTIAL flag. In all examples, the initial data item is 20
-bytes in length:
- ABCDEFGHIJ0123456789
-
-Result: The 20 bytes at offset 0 are replaced by the 20 bytes of data,
-i.e., the entire record is replaced.
-
-ABCDEFGHIJ0123456789 -> abcdefghijabcdefghij
-
-Result: The 0 bytes at offset 20 are replaced by the 10 bytes of data,
-i.e., the record is extended by 10 bytes.
-
-ABCDEFGHIJ0123456789 -> ABCDEFGHIJ0123456789abcdefghij
-
-Result: The 5 bytes at offset 10 are replaced by the 10 bytes of data.
-
-ABCDEFGHIJ0123456789 -> ABCDEFGHIJabcdefghij56789
-
-Result: The 0 bytes at offset 10 are replaced by the 10 bytes of data,
-i.e., 10 bytes are inserted into the record.
-
-ABCDEFGHIJ0123456789 -> ABCDEFGHIJabcdefghij0123456789
-
-Result: The 15 bytes at offset 2 are replaced by the 10 bytes of data.
-
-ABCDEFGHIJ0123456789 -> ABabcdefghij789
-
-Result: The 0 bytes at offset 0 are replaced by the 10 bytes of data,
-i.e., the 10 bytes are inserted at the beginning of the record.
-
-ABCDEFGHIJ0123456789 -> abcdefghijABCDEFGHIJ0123456789
-
-Result: The 10 bytes at offset 0 are replaced by the 0 bytes of data,
-i.e., the first 10 bytes of the record are discarded.
-
-ABCDEFGHIJ0123456789 -> 0123456789
-
-Result: The 0 bytes at offset 25 are replaced by the 10 bytes of data,
-i.e., 10 bytes are inserted into the record past the end of the current
-data (\0 represents a nul byte).
-
-ABCDEFGHIJ0123456789 -> ABCDEFGHIJ0123456789\0\0\0\0\0abcdefghij
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/put.html b/bdb/docs/ref/am/put.html
deleted file mode 100644
index 993dcbeb068..00000000000
--- a/bdb/docs/ref/am/put.html
+++ /dev/null
@@ -1,36 +0,0 @@
-
-
-
-
-
- The DB->put function is the standard interface for storing records into
-the database. In general, DB->put takes a key and stores the
-associated data into the database.
- There are a few flags that you can set to customize storage:
- If the database has been configured to support duplicate records, the
-DB->put function will add the new data value at the end of the duplicate
-set. If the database supports sorted duplicates, the new data value is
-inserted at the correct sorted location.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/stability.html b/bdb/docs/ref/am/stability.html
deleted file mode 100644
index b5f6d23864d..00000000000
--- a/bdb/docs/ref/am/stability.html
+++ /dev/null
@@ -1,49 +0,0 @@
-
-
-
-
-
- In the absence of locking, no guarantees are made about the stability of
-cursors in different processes or threads. However, the Btree, Queue
-and Recno access methods guarantee that cursor operations, interspersed
-with other cursor or non-cursor operations in the same thread of control
-will always return keys in order and will return each non-deleted key/data
-pair exactly once. Because the Hash access method uses a dynamic hashing
-algorithm, it cannot guarantee any form of stability in the presence of
-inserts and deletes unless locking is performed.
- If locking was specified when the Berkeley DB file was opened, but transactions
-are not in effect, the access methods provide repeatable reads with
-respect to the cursor. That is, a DB_CURRENT call on the cursor
-is guaranteed to return the same record as was returned on the last call
-to the cursor.
- With the exception of the Queue access method, in the presence of
-transactions, all access method calls between a call to txn_begin
-and a call to txn_abort or txn_commit provide degree 3
-consistency (serializable transactions).
- The Queue access method permits phantom records to appear between calls.
-That is, deleted records are not locked, therefore another transaction may
-replace a deleted record between two calls to retrieve it. The record would
-not appear in the first call but would be seen by the second call.
- For all access methods, a cursor scan of the database performed within
-the context of a transaction is guaranteed to return each key/data pair
-once and only once, except in the following case. If, while performing
-a cursor scan using the Hash access method, the transaction performing
-the scan inserts a new pair into the database, it is possible that duplicate
-key/data pairs will be returned.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/stat.html b/bdb/docs/ref/am/stat.html
deleted file mode 100644
index 3042ccfee00..00000000000
--- a/bdb/docs/ref/am/stat.html
+++ /dev/null
@@ -1,36 +0,0 @@
-
-
-
-
-
- The DB->stat function is the standard interface for obtaining database
-statistics. Generally, DB->stat returns a set of statistics
-about the underlying database, e.g., the number of key/data pairs in
-the database, how the database was originally configured, and so on.
- There are two flags that you can set to customize the returned statistics:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/sync.html b/bdb/docs/ref/am/sync.html
deleted file mode 100644
index 3d1d61e6231..00000000000
--- a/bdb/docs/ref/am/sync.html
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
-
-
-
- The DB->sync function is the standard interface for flushing all modified
-records from the database cache to disk.
- It is important to understand that flushing cached information
-to disk only minimizes the window of opportunity for corrupted data, it
-does not eliminate the possibility.
- While unlikely, it is possible for database corruption to happen if a
-system or application crash occurs while writing data to the database. To
-ensure that database corruption never occurs, applications must either:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/upgrade.html b/bdb/docs/ref/am/upgrade.html
deleted file mode 100644
index 21fa87a1eab..00000000000
--- a/bdb/docs/ref/am/upgrade.html
+++ /dev/null
@@ -1,50 +0,0 @@
-
-
-
-
-
- When upgrading to a new release of Berkeley DB, it may be necessary to upgrade
-the on-disk format of already-created database files. Berkeley DB
-database upgrades are done in place, and so are potentially
-destructive. This means that if the system crashes during the upgrade
-procedure, or if the upgrade procedure runs out of disk space, the
-databases may be left in an inconsistent and unrecoverable state. To
-guard against failure, the procedures outlined in
-Upgrading Berkeley DB installations
-should be carefully followed. If you are not performing catastrophic
-archival as part of your application upgrade process, you should at
-least copy your database to archival media, verify that your archival
-media is error-free and readable, and that copies of your backups are
-stored off-site!
- The actual database upgrade is done using the DB->upgrade
-method, or by dumping the database using the old version of the Berkeley DB
-software and reloading it using the current version.
- After an upgrade, Berkeley DB applications must be recompiled to use the new
-Berkeley DB library before they can access an upgraded database.
-There is no guarantee that applications compiled against
-previous releases of Berkeley DB will work correctly with an upgraded database
-format. Nor is there any guarantee that applications compiled against
-newer releases of Berkeley DB will work correctly with the previous database
-format. We do guarantee that any archived database may be upgraded
-using a current Berkeley DB software release and the DB->upgrade
-method, and there is no need to step-wise upgrade the database using
-intermediate releases of Berkeley DB. Sites should consider archiving
-appropriate copies of their application or application sources if they
-may need to access archived databases without first upgrading them.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am/verify.html b/bdb/docs/ref/am/verify.html
deleted file mode 100644
index 5c975dd8c58..00000000000
--- a/bdb/docs/ref/am/verify.html
+++ /dev/null
@@ -1,50 +0,0 @@
-
-
-
-
-
- The DB->verify method is the standard interface for verifying
-that a file, and any databases it may contain, are uncorrupted. In
-addition, the method may optionally be called with a file stream
-argument to which all key/data pairs found in the database are output.
-There are two modes for finding key/data pairs to be output:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/bt_compare.html b/bdb/docs/ref/am_conf/bt_compare.html
deleted file mode 100644
index bf824ca3597..00000000000
--- a/bdb/docs/ref/am_conf/bt_compare.html
+++ /dev/null
@@ -1,85 +0,0 @@
-
-
-
-
-
- The Btree data structure is a sorted, balanced tree structure storing
-associated key/data pairs. By default, the sort order is lexicographical,
-with shorter keys collating before longer keys. The user can specify the
-sort order for the Btree by using the DB->set_bt_compare function.
- Sort routines are passed pointers to keys as arguments. The keys are
-represented as DBT structures. The routine must return an integer
-less than, equal to, or greater than zero if the first argument is
-considered to be respectively less than, equal to, or greater than the
-second argument. The only fields that the routines may examine in the
-DBT structures are data and size fields.
- An example routine that might be used to sort integer keys in the database
-is as follows:
-
- /*
- * Returns:
- * < 0 if a < b
- * = 0 if a = b
- * > 0 if a > b
- */
- memcpy(&ai, a->data, sizeof(int));
- memcpy(&bi, b->data, sizeof(int));
- return (ai - bi);
-}
- Note that the data must first be copied into memory that is appropriately
-aligned, as Berkeley DB does not guarantee any kind of alignment of the
-underlying data, including for comparison routines. When writing
-comparison routines, remember that databases created on machines of
-different architectures may have different integer byte orders, for which
-your code may need to compensate.
- An example routine that might be used to sort keys based on the first
-five bytes of the key (ignoring any subsequent bytes) is as follows:
-
- /*
- * Returns:
- * < 0 if a < b
- * = 0 if a = b
- * > 0 if a > b
- */
- for (p1 = a->data, p2 = b->data, len = 5; len--; ++p1, ++p2)
- if (*p1 != *p2)
- return ((long)*p1 - (long)*p2);
- return (0);
-} All comparison functions must cause the keys in the database to be
-well-ordered. The most important implication of being well-ordered is
-that the key relations must be transitive, that is, if key A is less
-than key B, and key B is less than key C, then the comparison routine
-must also return that key A is less than key C. In addition, comparisons
-will only be able to return 0 when comparing full length keys; partial
-key comparisons must always return a result less than or greater than 0.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/bt_minkey.html b/bdb/docs/ref/am_conf/bt_minkey.html
deleted file mode 100644
index f80ecf1dfb8..00000000000
--- a/bdb/docs/ref/am_conf/bt_minkey.html
+++ /dev/null
@@ -1,53 +0,0 @@
-
-
-
-
-
- The number of keys stored on each page affects the size of a Btree and
-how it is maintained. Therefore, it also affects the retrieval and search
-performance of the tree. For each Btree, Berkeley DB computes a maximum key
-and data size. This size is a function of the page size and the fact that
-at least two key/data pairs must fit on any Btree page. Whenever key or
-data items exceed the calculated size, they are stored on overflow pages
-instead of in the standard Btree leaf pages.
- Applications may use the DB->set_bt_minkey function to change the minimum
-number of keys that must fit on a Btree page from two to another value.
-Altering this value in turn alters the on-page maximum size, and can be
-used to force key and data items which would normally be stored in the
-Btree leaf pages onto overflow pages.
- Some data sets can benefit from this tuning. For example, consider an
-application using large page sizes, with a data set almost entirely
-consisting of small key and data items, but with a few large items. By
-setting the minimum number of keys that must fit on a page, the
-application can force the outsized items to be stored on overflow pages.
-That in turn can potentially keep the tree more compact, that is, with
-fewer internal levels to traverse during searches.
- The following calculation is similar to the one performed by the Btree
-implementation. (The minimum_keys value is multiplied by 2
-because each key/data pair requires 2 slots on a Btree page.)
- Using this calculation, if the page size is 8KB and the default
-minimum_keys value of 2 is used, then any key or data items
-larger than 2KB will be forced to an overflow page. If an application
-were to specify a minimum_key value of 100, then any key or data
-items larger than roughly 40 bytes would be forced to overflow pages.
- It is important to remember that accesses to overflow pages do not perform
-as well as accesses to the standard Btree leaf pages, and so setting the
-value incorrectly can result in overusing overflow pages and decreasing
-the application's overall performance.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/bt_prefix.html b/bdb/docs/ref/am_conf/bt_prefix.html
deleted file mode 100644
index 621de75fa6b..00000000000
--- a/bdb/docs/ref/am_conf/bt_prefix.html
+++ /dev/null
@@ -1,66 +0,0 @@
-
-
-
-
-
- The Berkeley DB Btree implementation maximizes the number of keys that can be
-stored on an internal page by storing only as many bytes of each key as
-are necessary to distinguish it from adjacent keys. The prefix comparison
-routine is what determines this minimum number of bytes (i.e., the length
-of the unique prefix), that must be stored. A prefix comparison function
-for the Btree can be specified by calling DB->set_bt_prefix.
- The prefix comparison routine must be compatible with the overall
-comparison function of the Btree, since what distinguishes any two keys
-depends entirely on the function used to compare them. This means that
-if a prefix comparison routine is specified by the application, a
-compatible overall comparison routine must also have been specified.
- Prefix comparison routines are passed pointers to keys as arguments. The
-keys are represented as DBT structures. The prefix comparison
-function must return the number of bytes of the second key argument that
-are necessary to determine if it is greater than the first key argument.
-If the keys are equal, the length of the second key should be returned.
-The only fields that the routines may examine in the DBT
-structures are data and size fields.
- An example prefix comparison routine follows:
-
- cnt = 1;
- len = a->size > b->size ? b->size : a->size;
- for (p1 =
- a->data, p2 = b->data; len--; ++p1, ++p2, ++cnt)
- if (*p1 != *p2)
- return (cnt);
- /*
- * They match up to the smaller of the two sizes.
- * Collate the longer after the shorter.
- */
- if (a->size < b->size)
- return (a->size + 1);
- if (b->size < a->size)
- return (b->size + 1);
- return (b->size);
-} The usefulness of this functionality is data dependent, but in some data
-sets can produce significantly reduced tree sizes and faster search times.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/bt_recnum.html b/bdb/docs/ref/am_conf/bt_recnum.html
deleted file mode 100644
index cdf8970e553..00000000000
--- a/bdb/docs/ref/am_conf/bt_recnum.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- The Btree access method optionally supports retrieval by logical record
-numbers). To configure a Btree to support record numbers, call the
-DB->set_flags function with the DB_RECNUM flag.
- Configuring a Btree for record numbers should not be done lightly.
-While often useful, it requires that storing items into the database
-be single-threaded, which can severely impact application throughput.
-Generally it should be avoided in trees with a need for high write
-concurrency.
- To determine a key's record number, use the DB_GET_RECNO flag
-to the DBcursor->c_get function.
- To retrieve by record number, use the DB_SET_RECNO flag to the
-DB->get and DBcursor->c_get functions.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/byteorder.html b/bdb/docs/ref/am_conf/byteorder.html
deleted file mode 100644
index e0eef8a45f0..00000000000
--- a/bdb/docs/ref/am_conf/byteorder.html
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
-
-
-
- The database files created by Berkeley DB can be created in either little- or
-big-endian formats.
- The byte order used for the underlying database can be specified by
-calling the DB->set_lorder function. If no order is selected, the
-native format of the machine on which the database is created will be
-used.
- Berkeley DB databases are architecture independent, and any format database can
-be used on a machine with a different native format. In this case, as
-each page that is read into or written from the cache must be converted
-to or from the host format, and databases with non-native formats will
-incur a performance penalty for the run-time conversion.
- It is important to note that the Berkeley DB access methods do no data
-conversion for application specified data. Key/data pairs written on a
-little-endian format architecture will be returned to the application
-exactly as they were written when retrieved on a big-endian format
-architecture.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/cachesize.html b/bdb/docs/ref/am_conf/cachesize.html
deleted file mode 100644
index d0534767fb0..00000000000
--- a/bdb/docs/ref/am_conf/cachesize.html
+++ /dev/null
@@ -1,86 +0,0 @@
-
-
-
-
-
- The size of the cache used for the underlying database can be specified
-by calling the DB->set_cachesize function.
-Choosing a cache size is, unfortunately, an art. Your cache must be at
-least large enough for your working set plus some overlap for unexpected
-situations.
- When using the Btree access method, you must have a cache big enough for
-the minimum working set for a single access. This will include a root
-page, one or more internal pages (depending on the depth of your tree),
-and a leaf page. If your cache is any smaller than that, each new page
-will force out the least-recently-used page, and Berkeley DB will re-read the
-root page of the tree anew on each database request.
- If your keys are of moderate size (a few tens of bytes) and your pages
-are on the order of 4K to 8K, most Btree applications
-will be only three levels. For
-example, using 20 byte keys with 20 bytes of data associated with each
-key, a 8KB page can hold roughly 400 keys and 200 key/data pairs, so a
-fully populated three-level Btree will hold 32 million key/data pairs,
-and a tree with only a 50% page-fill factor will still hold 16 million
-key/data pairs. We rarely expect trees to exceed five levels, although
-Berkeley DB will support trees up to 255 levels.
- The rule-of-thumb is that cache is good, and more cache is better.
-Generally, applications benefit from increasing the cache size up to a
-point, at which the performance will stop improving as the cache size
-increases. When this point is reached, one of two things have happened:
-either the cache is large enough that the application is almost never
-having to retrieve information from disk, or, your application is doing
-truly random accesses, and therefore increasing size of the cache doesn't
-significantly increase the odds of finding the next requested information
-in the cache. The latter is fairly rare -- almost all applications show
-some form of locality of reference.
- That said, it is important not to increase your cache size beyond the
-capabilities of your system, as that will result in reduced performance.
-Under many operating systems, tying down enough virtual memory will cause
-your memory and potentially your program to be swapped. This is
-especially likely on systems without unified OS buffer caches and virtual
-memory spaces, as the buffer cache was allocated at boot time and so
-cannot be adjusted based on application requests for large amounts of
-virtual memory.
- For example, even if accesses are truly random within a Btree, your
-access pattern will favor internal pages to leaf pages, so your cache
-should be large enough to hold all internal pages. In the steady state,
-this requires at most one I/O per operation to retrieve the appropriate
-leaf page.
- You can use the db_stat utility to monitor the effectiveness of
-your cache. The following output is excerpted from the output of that
-utility's -m option:
- The statistics for this cache say that there have been 4,273 requests of
-the cache, and only 116 of those requests required an I/O from disk. This
-means that the cache is working well, yielding a 97% cache hit rate. The
-db_stat utility will present these statistics both for the cache
-as a whole and for each file within the cache separately.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/dup.html b/bdb/docs/ref/am_conf/dup.html
deleted file mode 100644
index eec5302cb2f..00000000000
--- a/bdb/docs/ref/am_conf/dup.html
+++ /dev/null
@@ -1,71 +0,0 @@
-
-
-
-
-
- The Btree and Hash access methods support the creation of multiple data
-items for a single key item. By default, multiple data items are not
-permitted, and each database store operation will overwrite any previous
-data item for that key. To configure Berkeley DB for duplicate data items, call
-the DB->set_flags function with the DB_DUP flag.
- By default, Berkeley DB stores duplicates in the order in which they were added,
-that is, each new duplicate data item will be stored after any already
-existing data items. This default behavior can be overridden by using
-the DBcursor->c_put function and one of the DB_AFTER, DB_BEFORE
-DB_KEYFIRST or DB_KEYLAST flags. Alternatively, Berkeley DB
-may be configured to sort duplicate data items as described below.
- When stepping through the database sequentially, duplicate data items will
-be returned individually, as a key/data pair, where the key item only
-changes after the last duplicate data item has been returned. For this
-reason, duplicate data items cannot be accessed using the
-DB->get function, as it always returns the first of the duplicate data
-items. Duplicate data items should be retrieved using the Berkeley DB cursor
-interface, DBcursor->c_get.
- There is an interface flag that permits applications to request the
-following data item only if it is a duplicate data item of the
-current entry, see DB_NEXT_DUP for more information. There is an
-interface flag that permits applications to request the following data
-item only if it is not a duplicate data item of the current
-entry, see DB_NEXT_NODUP and DB_PREV_NODUP for more
-information.
- It is also possible to maintain duplicate records in sorted order. Sorting
-duplicates will significantly increase performance when searching them
-and performing logical joins, common operations when creating secondary
-indexes. To configure Berkeley DB to sort duplicate data items, the application
-must call the DB->set_flags function with the DB_DUPSORT flag (in
-addition to the DB_DUP flag). In addition, a custom sorting
-function may be specified using the DB->set_dup_compare function. If the
-DB_DUPSORT flag is given, but no comparison routine is specified,
-then Berkeley DB defaults to the same lexicographical sorting used for Btree
-keys, with shorter items collating before longer items.
- If the duplicate data items are unsorted, applications may store identical
-duplicate data items, or, for those that just like the way it sounds,
-duplicate duplicates.
- In this release it is an error to attempt to store identical
-duplicate data items when duplicates are being stored in a sorted order.
-This restriction is expected to be lifted in a future release. There is
-an interface flag that permits applications to disallow storing duplicate
-data items when the database has been configured for sorted duplicates,
-see DB_NODUPDATA for more information. Applications not wanting
-to permit duplicate duplicates in databases configured for sorted
-duplicates should begin using the DB_NODUPDATA flag immediately.
- For further information on how searching and insertion behaves in the
-presence of duplicates (sorted or not), see the DB->get,
-DB->put, DBcursor->c_get and DBcursor->c_put documentation.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/extentsize.html b/bdb/docs/ref/am_conf/extentsize.html
deleted file mode 100644
index 15d940c152d..00000000000
--- a/bdb/docs/ref/am_conf/extentsize.html
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
-
-
-
- In Queue databases, records are allocated sequentially and directly
-mapped to an offset within the file storage for the database. As
-records are deleted from the Queue, pages will become empty and will
-not be reused in normal queue operations. To facilitate the reclamation
-of disk space a Queue may be partitioned into extents. Each extent is
-kept in a separate physical file. Extent files are automatically
-created as needed and destroyed when they are emptied of records.
- The extent size specifies the number of pages that make up each extent.
-By default, if no extent size is specified, the Queue resides in a
-single file and disk space is not reclaimed. In choosing an extent size
-there is a tradeoff between the amount of disk space used and the
-overhead of creating and deleting files. If the extent size is too
-small, the system will pay a performance penalty, creating and deleting
-files frequently. In addition, if the active part of the queue spans
-many files, all those files will need to be open at the same time,
-consuming system and process file resources.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/h_ffactor.html b/bdb/docs/ref/am_conf/h_ffactor.html
deleted file mode 100644
index 6c30f0fc39e..00000000000
--- a/bdb/docs/ref/am_conf/h_ffactor.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- The density, or page fill factor, is an approximation of the number of
-keys allowed to accumulate in any one bucket, determining when the hash
-table grows or shrinks. If you know the average sizes of the keys and
-data in your dataset, setting the fill factor can enhance performance.
-A reasonable rule to use to compute fill factor is:
- The desired density within the hash table can be specified by calling
-the DB->set_h_ffactor function. If no density is specified, one will
-be selected dynamically as pages are filled.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/h_hash.html b/bdb/docs/ref/am_conf/h_hash.html
deleted file mode 100644
index d42edee1c07..00000000000
--- a/bdb/docs/ref/am_conf/h_hash.html
+++ /dev/null
@@ -1,39 +0,0 @@
-
-
-
-
-
- The database hash determines in which bucket a particular key will reside.
-The goal of hashing keys is to distribute keys equally across the database
-pages, therefore it is important that the hash function work well with
-the specified keys so that the resulting bucket usage is relatively
-uniform. A hash function that does not work well can effectively turn
-into a sequential list.
- No hash performs equally well on all possible data sets. It is possible
-that applications may find that the default hash function performs poorly
-with a particular set of keys. The distribution resulting from the hash
-function can be checked using db_stat utility. By comparing the
-number of hash buckets and the number of keys, one can decide if the entries
-are hashing in a well-distributed manner.
- The hash function for the hash table can be specified by calling the
-DB->set_h_hash function. If no hash function is specified, a default
-function will be used. Any application-specified hash function must
-take a reference to a DB object, a pointer to a byte string and
-its length, as arguments and return an unsigned, 32-bit hash value.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/h_nelem.html b/bdb/docs/ref/am_conf/h_nelem.html
deleted file mode 100644
index 8c510d6db04..00000000000
--- a/bdb/docs/ref/am_conf/h_nelem.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-
-
-
- When setting up the hash database, knowing the expected number of elements
-that will be stored in the hash table is useful. This value can be used
-by the Hash access method implementation to more accurately construct the
-necessary number of buckets that the database will eventually require.
- The anticipated number of elements in the hash table can be specified by
-calling the DB->set_h_nelem function. If not specified, or set too low,
-hash tables will expand gracefully as keys are entered, although a slight
-performance degradation may be noticed. In order for the estimated number
-of elements to be a useful value to Berkeley DB, the DB->set_h_ffactor function
-must also be called to set the page fill factor.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/intro.html b/bdb/docs/ref/am_conf/intro.html
deleted file mode 100644
index 15fed60f612..00000000000
--- a/bdb/docs/ref/am_conf/intro.html
+++ /dev/null
@@ -1,45 +0,0 @@
-
-
-
-
-
- Berkeley DB currently offers four access methods: Btree, Hash, Queue and Recno.
- The Btree access method is an implementation of a sorted, balanced tree
-structure. Searches, insertions, and deletions in the tree all take O(log
-base_b N) time, where base_b is the average number of keys per page, and
-N is the total number of keys stored. Often, inserting ordered data into
-Btree implementations results in pages that are only half-full. Berkeley DB
-makes ordered (or inverse ordered) insertion the best case, resulting in
-nearly full-page space utilization.
- The Hash access method data structure is an implementation of Extended
-Linear Hashing, as described in "Linear Hashing: A New Tool for File and
-Table Addressing", Witold Litwin, Proceedings of the 6th
-International Conference on Very Large Databases (VLDB), 1980.
- The Queue access method stores fixed-length records with logical record
-numbers as keys. It is designed for fast inserts at the tail and has a
-special cursor consume operation that deletes and returns a record from
-the head of the queue. The Queue access method uses record level locking.
- The Recno access method stores both fixed and variable-length records with
-logical record numbers as keys, optionally backed by a flat text (byte
-stream) file.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/logrec.html b/bdb/docs/ref/am_conf/logrec.html
deleted file mode 100644
index fd9fb0141d6..00000000000
--- a/bdb/docs/ref/am_conf/logrec.html
+++ /dev/null
@@ -1,45 +0,0 @@
-
-
-
-
-
- The Berkeley DB Btree, Queue and Recno access methods can operate on logical
-record numbers. In all cases for the Queue and Recno access methods,
-and in some cases with the Btree access method, a record number is
-specified to reference a specific key/data pair. In the case of Btree
-supporting duplicate data items, the logical record number refers to a
-key and all of its data items.
- Record numbers are 32-bit unsigned types, which limits the number of
-logical records in a database to 4,294,967,296. The first record in the
-database is record number 1.
- Record numbers in Recno databases can be configured to run in either
-mutable or fixed mode: mutable, where logical record numbers change as
-records are deleted or inserted, and fixed, where record numbers never
-change regardless of the database operation. Record numbers in Btree
-databases are always mutable, and as records are deleted or inserted, the
-logical record number for other records in the database can change. See
-Logically renumbering records for
-more information.
- Record numbers in Queue databases are always fixed, and never change
-regardless of the database operation.
- Configuring Btree databases to support record numbers can severely limit
-the throughput of applications with multiple concurrent threads writing
-the database, because locations used to store record counts often become
-hot spots that many different threads all need to update.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/malloc.html b/bdb/docs/ref/am_conf/malloc.html
deleted file mode 100644
index 12e57383c5e..00000000000
--- a/bdb/docs/ref/am_conf/malloc.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- Berkeley DB can allocate memory for returned key/data pairs which then becomes
-the responsibility of the application. See DB_DBT_MALLOC or
-DB_DBT_REALLOC for further information.
- On systems where there may be multiple library versions of malloc (notably
-Windows NT), the Berkeley DB library could allocate memory from a different heap
-than the application will use to free it. To avoid this problem, the
-allocation routine to be used for allocating such key/data items can be
-specified by calling the DB->set_malloc or
-DB->set_realloc functions. If no allocation function is specified, the
-underlying C library functions are used.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/pagesize.html b/bdb/docs/ref/am_conf/pagesize.html
deleted file mode 100644
index 41cab5ec439..00000000000
--- a/bdb/docs/ref/am_conf/pagesize.html
+++ /dev/null
@@ -1,66 +0,0 @@
-
-
-
-
-
- The size of the pages used in the underlying database can be specified by
-calling the DB->set_pagesize function. The minimum page size is 512 bytes
-and the maximum page size is 64K bytes, and must be a power of two. If
-no page size is specified by the application, a page size is selected
-based on the underlying filesystem I/O block size. (A page size selected
-in this way has a lower limit of 512 bytes and an upper limit of 16K
-bytes.)
- There are four issues to consider when selecting a pagesize: overflow
-record sizes, locking, I/O efficiency, and recoverability.
- First, the page size implicitly sets the size of an overflow record.
-Overflow records are key or data items that are too large to fit on a
-normal database page because of their size, and are therefore stored in
-overflow pages. Overflow pages are pages that exist outside of the normal
-database structure. For this reason, there is often a significant
-performance penalty associated with retrieving or modifying overflow
-records. Selecting a page size that is too small, and which forces the
-creation of large numbers of overflow pages, can seriously impact the
-performance of an application.
- Second, in the Btree, Hash and Recno Access Methods, the finest-grained
-lock that Berkeley DB acquires is for a page. (The Queue Access Method
-generally acquires record-level locks rather than page-level locks.)
-Selecting a page size that is too large, and which causes threads or
-processes to wait because other threads of control are accessing or
-modifying records on the same page, can impact the performance of your
-application.
- Third, the page size specifies the granularity of I/O from the database
-to the operating system. Berkeley DB will give a page-sized unit of bytes to
-the operating system to be scheduled for writing to the disk. For many
-operating systems, there is an internal block size which is used
-as the granularity of I/O from the operating system to the disk. If the
-page size is smaller than the block size, the operating system may be
-forced to read a block from the disk, copy the page into the buffer it
-read, and then write out the block to disk. Obviously, it will be much
-more efficient for Berkeley DB to write filesystem-sized blocks to the operating
-system and for the operating system to write those same blocks to the
-disk. Selecting a page size that is too small, and which causes the
-operating system to coalesce or otherwise manipulate Berkeley DB pages, can
-impact the performance of your application. Alternatively, selecting a
-page size that is too large may cause Berkeley DB and the operating system to
-write more data than is strictly necessary.
- Fourth, when using the Berkeley DB Transactional Data Store product, the page size may affect the errors
-from which your database can recover See
-Berkeley DB Recoverability for more
-information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/re_source.html b/bdb/docs/ref/am_conf/re_source.html
deleted file mode 100644
index 2095a96983a..00000000000
--- a/bdb/docs/ref/am_conf/re_source.html
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-
-
-
- It is possible to back any Recno database (either fixed or variable
-length) with a flat-text source file. This provides fast read (and
-potentially write) access to databases that are normally created and
-stored as flat-text files. The backing source file may be specified by
-calling the DB->set_re_source function.
- The backing source file will be read to initialize the database. In the
-case of variable length records, the records are assumed to be separated
-as described for the DB->set_re_delim function interface. For example,
-standard UNIX byte stream files can be interpreted as a sequence of
-variable length records separated by ASCII newline characters. This is
-the default.
- When cached data would normally be written back to the underlying database
-file (e.g., DB->close or DB->sync functions are called), the
-in-memory copy of the database will be written back to the backing source
-file.
- The backing source file must already exist (but may be zero-length) when
-DB->open is called. By default, the backing source file is read
-lazily, i.e., records are not read from the backing source file until they
-are requested by the application. If multiple processes (not threads) are
-accessing a Recno database concurrently and either inserting or deleting
-records, the backing source file must be read in its entirety before more
-than a single process accesses the database, and only that process should
-specify the backing source file as part of the DB->open call.
-This can be accomplished by calling the DB->set_flags function with the
-DB_SNAPSHOT flag.
- Reading and writing the backing source file cannot be transactionally
-protected because it involves filesystem operations that are not part of
-the Berkeley DB transaction methodology. For this reason, if a temporary
-database is used to hold the records (a NULL was specified as the file
-argument to DB->open), it is possible to lose the
-contents of the backing source file if the system crashes at the right
-instant. If a permanent file is used to hold the database (a file name
-was specified as the file argument to DB->open), normal database
-recovery on that file can be used to prevent information loss. It is
-still possible that the contents of the backing source file itself will
-be corrupted or lost if the system crashes.
- For all of the above reasons, the backing source file is generally used
-to specify databases that are read-only for Berkeley DB applications, and that
-are either generated on the fly by software tools, or modified using a
-different mechanism such as a text editor.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/recno.html b/bdb/docs/ref/am_conf/recno.html
deleted file mode 100644
index 1a7128e0e75..00000000000
--- a/bdb/docs/ref/am_conf/recno.html
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
-
-
-
- When using fixed- or variable-length record-based databases, particularly
-with flat-text backing files, there are several items that the user can
-control. The Recno access method can be used to store either variable-
-or fixed-length data items. By default, the Recno access method stores
-variable-length data items. The Queue access method can only store
-fixed-length data items.
- When using the Recno access method to store variable-length records,
-records read from any backing source file are separated by a specific
-byte value which marks the end of one record and the beginning of the
-next. This delimiting value is ignored except when reading records from
-a backing source file, that is, records may be stored into the database
-that include the delimiter byte. However, if such records are written
-out to the backing source file and the backing source file is
-subsequently read into a database, the records will be split where
-delimiting bytes were found.
- For example, UNIX text files can usually be interpreted as a sequence of
-variable-length records separated by ASCII newline characters. This byte
-value (ASCII 0x0a) is the default delimiter. Applications may specify a
-different delimiting byte using the DB->set_re_delim interface.
-If no backing source file is being used, there is no reason to set the
-delimiting byte value.
- When using the Recno or Queue access methods to store fixed-length
-records, the record length must be specified. Since the Queue access
-method always uses fixed-length records, the user must always set the
-record length prior to creating the database. Setting the record length
-is what causes the Recno access method to store fixed-length, not
-variable-length, records.
- The length of the records is specified by calling the
-DB->set_re_len function. The default length of the records is 0 bytes.
-Any record read from a backing source file or otherwise stored in the
-database that is shorter than the declared length will automatically be
-padded as described for the DB->set_re_pad function. Any record stored
-that is longer than the declared length results in an error. For
-further information on backing source files, see
-Flat-text backing files.
- When storing fixed-length records in a Queue or Recno database, a pad
-character may be specified by calling the DB->set_re_pad function. Any
-record read from the backing source file or otherwise stored in the
-database that is shorter than the expected length will automatically be
-padded with this byte value. If fixed-length records are specified but
-no pad value is specified, a space character (0x20 in the ASCII
-character set) will be used. For further information on backing source
-files, see Flat-text backing
-files.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/renumber.html b/bdb/docs/ref/am_conf/renumber.html
deleted file mode 100644
index 7c3594dff66..00000000000
--- a/bdb/docs/ref/am_conf/renumber.html
+++ /dev/null
@@ -1,80 +0,0 @@
-
-
-
-
-
- Records stored in the Queue and Recno access methods are accessed by
-logical record number. In all cases in Btree databases, and optionally
-in Recno databases (see the DB->set_flags function and the
-DB_RENUMBER flag for more information), record numbers are
-mutable. This means that the record numbers may change as records are
-added to and deleted from the database. The deletion of record number
-4 causes any records numbered 5 and higher to be renumbered downward by
-1; the addition of a new record after record number 4 causes any
-records numbered 5 and higher to be renumbered upward by 1. In all
-cases in Queue databases, and by default in Recno databases, record
-numbers are not mutable, and the addition or deletion of records to the
-database will not cause already-existing record numbers to change. For
-this reason, new records cannot be inserted between already-existing
-records in databases with immutable record numbers.
- Cursors pointing into a Btree database or a Recno database with mutable
-record numbers maintain a reference to a specific record, rather than
-a record number, that is, the record they reference does not change as
-other records are added or deleted. For example, if a database contains
-three records with the record numbers 1, 2, and 3, and the data items
-"A", "B", and "C", respectively, the deletion of record number 2 ("B")
-will cause the record "C" to be renumbered downward to record number 2.
-A cursor positioned at record number 3 ("C") will be adjusted and
-continue to point to "C" after the deletion. Similarly, a cursor
-previously referencing the now deleted record number 2 will be
-positioned between the new record numbers 1 and 2, and an insertion
-using that cursor will appear between those records. In this manner
-records can be added and deleted to a database without disrupting the
-sequential traversal of the database by a cursor.
- Only cursors created using a single DB handle can adjust each
-other's position in this way, however. If multiple DB handles
-have a renumbering Recno database open simultaneously (as when multiple
-processes share a single database environment), a record referred to by
-one cursor could change underfoot if a cursor created using another
-DB handle inserts or deletes records into the database. For
-this reason, applications using Recno databases with mutable record
-numbers will usually make all accesses to the database using a single
-DB handle and cursors created from that handle, or will
-otherwise single-thread access to the database, e.g., by using the
-Berkeley DB Concurrent Data Store product.
- In any Queue or Recno databases, creating new records will cause the
-creation of multiple records if the record number being created is more
-than one greater than the largest record currently in the database. For
-example, creating record number 28, when record 25 was previously the
-last record in the database, will implicitly create records 26 and 27
-as well as 28. All first, last, next and previous cursor operations
-will automatically skip over these implicitly created records. So, if
-record number 5 is the only record the application has created,
-implicitly creating records 1 through 4, the DBcursor->c_get interface
-with the DB_FIRST flag will return record number 5, not record
-number 1. Attempts to explicitly retrieve implicitly created records
-by their record number will result in a special error return,
-DB_KEYEMPTY.
- In any Berkeley DB database, attempting to retrieve a deleted record, using
-a cursor positioned on the record, results in a special error return,
-DB_KEYEMPTY. In addition, when using Queue databases or Recno
-databases with immutable record numbers, attempting to retrieve a deleted
-record by its record number will also result in the DB_KEYEMPTY
-return.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/am_conf/select.html b/bdb/docs/ref/am_conf/select.html
deleted file mode 100644
index 3838b34673e..00000000000
--- a/bdb/docs/ref/am_conf/select.html
+++ /dev/null
@@ -1,116 +0,0 @@
-
-
-
-
-
- The Berkeley DB access method implementation unavoidably interacts with each
-application's data set, locking requirements and data access patterns.
-For this reason, one access method may result in dramatically better
-performance for an application than another one. Applications whose data
-could be stored in more than one access method may want to benchmark their
-performance using the different candidates.
- One of the strengths of Berkeley DB is that it provides multiple access methods
-with almost identical interfaces to the different access methods. This
-means that it is simple to modify an application to use a different access
-method. Applications can easily benchmark the different Berkeley DB access
-methods against each other for their particular data set and access pattern.
- Most applications choose between using the Btree or Hash access methods
-or between using the Queue and Recno access methods, because each of the
-two pairs offer similar functionality.
- The Hash and Btree access methods should be used when logical record
-numbers are not the primary key used for data access. (If logical record
-numbers are a secondary key used for data access, the Btree access method
-is a possible choice, as it supports simultaneous access by a key and a
-record number.)
- Keys in Btrees are stored in sorted order and the relationship between
-them is defined by that sort order. For this reason, the Btree access
-method should be used when there is any locality of reference among keys.
-Locality of reference means that accessing one particular key in the
-Btree implies that the application is more likely to access keys near to
-the key being accessed, where "near" is defined by the sort order. For
-example, if keys are timestamps, and it is likely that a request for an
-8AM timestamp will be followed by a request for a 9AM timestamp, the
-Btree access method is generally the right choice. Or, for example, if
-the keys are names, and the application will want to review all entries
-with the same last name, the Btree access method is again a good choice.
- There is little difference in performance between the Hash and Btree
-access methods on small data sets, where all, or most of, the data set
-fits into the cache. However, when a data set is large enough that
-significant numbers of data pages no longer fit into the cache, then the
-Btree locality of reference described above becomes important for
-performance reasons. For example, there is no locality of reference for
-the Hash access method, and so key "AAAAA" is as likely to be stored on
-the same data page with key "ZZZZZ" as with key "AAAAB". In the Btree
-access method, because items are sorted, key "AAAAA" is far more likely
-to be near key "AAAAB" than key "ZZZZZ". So, if the application exhibits
-locality of reference in its data requests, then the Btree page read into
-the cache to satisfy a request for key "AAAAA" is much more likely to be
-useful to satisfy subsequent requests from the application than the Hash
-page read into the cache to satisfy the same request. This means that
-for applications with locality of reference, the cache is generally much
-"hotter" for the Btree access method than the Hash access method, and
-the Btree access method will make many fewer I/O calls.
- However, when a data set becomes even larger, the Hash access method can
-outperform the Btree access method. The reason for this is that Btrees
-contain more metadata pages than Hash databases. The data set can grow
-so large that metadata pages begin to dominate the cache for the Btree
-access method. If this happens, the Btree can be forced to do an I/O
-for each data request because the probability that any particular data
-page is already in the cache becomes quite small. Because the Hash access
-method has fewer metadata pages, its cache stays "hotter" longer in the
-presence of large data sets. In addition, once the data set is so large
-that both the Btree and Hash access methods are almost certainly doing
-an I/O for each random data request, the fact that Hash does not have to
-walk several internal pages as part of a key search becomes a performance
-advantage for the Hash access method as well.
- Application data access patterns strongly affect all of these behaviors,
-for example, accessing the data by walking a cursor through the database
-will greatly mitigate the large data set behavior describe above because
-each I/O into the cache will satisfy a fairly large number of subsequent
-data requests.
- In the absence of information on application data and data access
-patterns, for small data sets either the Btree or Hash access methods
-will suffice. For data sets larger than the cache, we normally recommend
-using the Btree access method. If you have truly large data, then the
-Hash access method may be a better choice. The db_stat utility
-is a useful tool for monitoring how well your cache is performing.
- The Queue or Recno access methods should be used when logical record
-numbers are the primary key used for data access. The advantage of the
-Queue access method is that it performs record level locking and for this
-reason supports significantly higher levels of concurrency than the Recno
-access method. The advantage of the Recno access method is that it
-supports a number of additional features beyond those supported by the
-Queue access method, such as variable-length records and support for
-backing flat-text files.
- Logical record numbers can be mutable or fixed: mutable, where logical
-record numbers can change as records are deleted or inserted, and fixed,
-where record numbers never change regardless of the database operation.
-It is possible to store and retrieve records based on logical record
-numbers in the Btree access method. However, those record numbers are
-always mutable, and as records are deleted or inserted, the logical record
-number for other records in the database will change. The Queue access
-method always runs in fixed mode, and logical record numbers never change
-regardless of the database operation. The Recno access method can be
-configured to run in either mutable or fixed mode.
- In addition, the Recno access method provides support for databases whose
-permanent storage is a flat text file and the database is used as a fast,
-temporary storage area while the data is being read or modified.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/arch/apis.html b/bdb/docs/ref/arch/apis.html
deleted file mode 100644
index d1ae91b5a74..00000000000
--- a/bdb/docs/ref/arch/apis.html
+++ /dev/null
@@ -1,74 +0,0 @@
-
-
-
-
-
- The Berkeley DB subsystems can be accessed through interfaces from multiple
-languages. The standard library interface is ANSI C. Applications can
-also use Berkeley DB via C++ or Java, as well as from scripting languages.
-Environments can be shared among applications written using any of theses
-APIs. For example, you might have a local server written in C or C++, a
-script for an administrator written in Perl or Tcl, and a web based user
-interface written in Java, all sharing a single database environment.
- The Berkeley DB library is written entirely in ANSI C. C applications use a
-single include file:
- The C++ classes provide a thin wrapper around the C API, with the major
-advantages being improved encapsulation and an optional exception
-mechanism for errors. C++ applications use a single include file:
- The classes and methods are named in a fashion that directly corresponds
-to structures and functions in the C interface. Likewise, arguments to
-methods appear in the same order as the C interface, except to remove the
-explicit this pointer. The #defines used for flags are identical
-between the C and C++ interfaces.
- As a rule, each C++ object has exactly one structure from the underlying
-C API associated with it. The C structure is allocated with each
-constructor call and deallocated with each destructor call. Thus, the
-rules the user needs to follow in allocating and deallocating structures
-are the same between the C and C++ interfaces.
- To ensure portability to many platforms, both new and old, Berkeley DB makes as
-few assumptions as possible about the C++ compiler and library. For
-example, it does not expect STL, templates or namespaces to be available.
-The newest C++ feature used is exceptions, which are used liberally to
-transmit error information. Even the use of exceptions can be disabled
-at runtime.
- The Java classes provide a layer around the C API that is almost identical
-to the C++ layer. The classes and methods are, for the most part
-identical to the C++ layer. Db constants and #defines are represented as
-"static final int" values. Error conditions are communicated as Java
-exceptions.
- As in C++, each Java object has exactly one structure from the underlying
-C API associated with it. The Java structure is allocated with each
-constructor or open call, but is deallocated only by the Java garbage
-collector. Because the timing of garbage collection is not predictable,
-applications should take care to do a close when finished with any object
-that has a close method.
- Berkeley DB supports the standard UNIX interfaces dbm (or its
-ndbm variant) and hsearch. After including a new header
-file and recompiling, dbm programs will run orders of magnitude
-faster and their underlying databases can grow as large as necessary.
-Historic dbm applications fail when some number of entries were
-inserted into the database, where the number depends on the effectiveness
-of the hashing function on the particular data set.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/arch/bigpic.gif b/bdb/docs/ref/arch/bigpic.gif
deleted file mode 100644
index 48c52aed5a2d1aee75052db2405d3d7e5389f01a..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 2589
zcmV+&3gY!gNk%v~VNn4w0e}Di00030|Nkri0000{0Wkpp0{)DTsmtvTqnxzbi?iOm
z`wxcVNS5Y_rs~SJ?hD8AOxN~}=lag~{tpZahs2`sh)gP%%%<}RjY_A~s`ZM^YPa03
z_X`e-$K
- The previous chapters in this Reference Guide have described applications
-that use the Berkeley DB Access Methods for fast data storage and retrieval.
-The applications we describe here and in subsequent chapters are similar
-in nature to the Access Method applications, but they are also fully
-recoverable in the face of application or system failure.
- Application code that only uses the Berkeley DB Access Methods might appear as
-follows:
- The underlying Berkeley DB architecture that supports this is:
- As you can see from this diagram, the application makes calls into the
-Access Methods, and the Access Methods use the underlying shared memory
-buffer cache to hold recently used file pages in main memory.
- When applications require recoverability, then their calls to the Access
-Methods must be wrapped in calls to the transaction subsystem. The
-application must inform Berkeley DB where to begin and end transactions, and
-must be prepared for the possibility that an operation may fail at any
-particular time, causing the transaction to abort.
- An example of transaction protected code might appear as follows:
-
- switch (ret = dbp->put(dbp, tid, &key, &data, 0)) {
- case DB_LOCK_DEADLOCK:
- (void)txn_abort(tid);
- goto retry;
- case 0:
- printf("db: %s: key stored.\n", (char *)key.data);
- break;
- default:
- dbenv->err(dbenv, ret, "dbp->put");
- exit (1);
- }
-
- if ((ret = txn_commit(tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_commit");
- exit (1);
- } In this example, the same operation is being done as before, however, it
-is wrapped in transaction calls. The transaction is started with
-txn_begin, and finished with txn_commit. If the operation
-fails due to a deadlock, then the transaction is aborted using
-txn_abort, after which the operation may be retried.
- There are actually five major subsystems in Berkeley DB, as follows:
- Here is a more complete picture of the Berkeley DB library:
- In this example, the application makes calls to the Access Methods and to
-the transaction subsystem. The Access Methods and transaction subsystem
-in turn make calls into the Buffer Pool, Locking and Logging subsystems
-on behalf of the application.
- While the underlying subsystems can each be called independently. For
-example, the Buffer Pool subsystem can be used apart from the rest of
-Berkeley DB by applications simply wanting a shared memory buffer pool, or
-the Locking subsystem may be called directly by applications that are
-doing their own locking outside of Berkeley DB. However, this usage is fairly
-rare, and most applications will either use only the Access Methods, or
-the Access Methods wrapped in calls to the transaction interfaces.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/arch/progmodel.html b/bdb/docs/ref/arch/progmodel.html
deleted file mode 100644
index 04284f4f37e..00000000000
--- a/bdb/docs/ref/arch/progmodel.html
+++ /dev/null
@@ -1,41 +0,0 @@
-
-
-
-
-
- The Berkeley DB distribution is a database library, where the library is linked
-into the address space of the code which uses it. The code using Berkeley DB
-may be an application or it may be a server providing functionality to a
-number of clients via some form of inter-process or remote-process
-communication (IPC/RPC).
- In the application model, one or more applications link the Berkeley DB library
-directly into their address spaces. There may be many threads of control
-in this model, as Berkeley DB supports locking for both multiple processes and
-for multiple threads within a process. This model provides significantly
-faster access to the database functionality, but implies trust among all
-threads of control sharing the database environment as they will have the
-ability to read, write and potentially corrupt each other's data.
- In the client-server model, developers write a database server application
-that accepts requests via some form of IPC and issues calls to the Berkeley DB
-interfaces based on those requests. In this model, the database server
-is the only application linking the Berkeley DB library into its address space.
-The client-server model trades performance for protection, as it does not
-require that the applications share a protection domain with the server,
-but IPC/RPC is slower than a function call. Of course, in addition, this
-model greatly simplifies the creation of network client-server applications.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/arch/script.html b/bdb/docs/ref/arch/script.html
deleted file mode 100644
index 411cff4600c..00000000000
--- a/bdb/docs/ref/arch/script.html
+++ /dev/null
@@ -1,29 +0,0 @@
-
-
-
-
-
- Two Perl APIs are distributed with the Berkeley DB release. The Perl interface
-to Berkeley DB version 1.85 is called DB_File. The Perl interface to Berkeley DB
-version 2 is called BerkeleyDB. See Using Berkeley DB with Perl for more information.
- A Tcl API is distributed with the Berkeley DB release. See
-Using Berkeley DB with Tcl for more
-information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/arch/smallpic.gif b/bdb/docs/ref/arch/smallpic.gif
deleted file mode 100644
index 5eb7ae8da588e4a92e07008845bed30c1cdf1297..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 1613
zcmV-T2D14_Nk%v~VNn4g0e}Di00030|Nkri0000{0U-eZ0{)DTsmtvTqnxzbi?iOm
z`wxcVNS5Y_rs~SJ?hD8AOxN~}=lag~{tpZahs2`sh)gP%%%<}RjY_A~s`ZM^YPa03
z_X`e-$K
- There are several stand-alone utilities that provide supporting
-functionality for the Berkeley DB environment:
- All of the functionality implemented for these utilities is also available
-as part of the standard Berkeley DB API. This means that threaded applications
-can easily create a thread that calls the same Berkeley DB functions as do the
-utilities. This often simplifies an application environment by removing
-the necessity for multiple processes to negotiate database and database
-environment creation and shutdown.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/aix.html b/bdb/docs/ref/build_unix/aix.html
deleted file mode 100644
index 102e1a01fbe..00000000000
--- a/bdb/docs/ref/build_unix/aix.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- Special compile-time flags are required when compiling threaded
-applications on AIX. If you are compiling a threaded application,
-you must compile with the _THREAD_SAFE flag and load with specific
-libraries, e.g., "-lc_r". Specifying the compiler name with a
-trailing "_r" usually performs the right actions for the system.
- The Berkeley DB library will automatically build with the correct options.
- AIX 4.1 only allows applications to map 10 system shared memory segments.
-In AIX 4.3 this has been raised to 256K segments, but only if you set the
-environment variable "export EXTSHM=ON".
- Berkeley DB does not include large-file support for AIX systems by default.
-Sleepycat Software has been told that the following changes will add
-large-file support on the AIX 4.2 and later releases, but we have not
-tested them ourselves.
- Add the following lines to the db_config.h file in your build
-directory:
- Change the source code for os/os_open.c to always specify the
-O_LARGEFILE flag to the open(2) system call.
- Recompile Berkeley DB from scratch.
- Note that the documentation for the IBM Visual Age compiler states that
-it does not not support the 64-bit filesystem APIs necessary for creating
-large files, and that the ibmcxx product must be used instead. We have
-not heard if the GNU gcc compiler supports the 64-bit APIs or not.
- Finally, to create large files under AIX, the filesystem has to be
-configured to support large files and the system wide user hard-limit for
-file sizes has to be greater than 1GB.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/conf.html b/bdb/docs/ref/build_unix/conf.html
deleted file mode 100644
index 289e9559e3a..00000000000
--- a/bdb/docs/ref/build_unix/conf.html
+++ /dev/null
@@ -1,143 +0,0 @@
-
-
-
-
-
- There are several options that you can specify when configuring Berkeley DB.
-While only the Berkeley DB specific ones are described here, most of the
-standard GNU autoconf options are available and supported. To see a
-complete list of the options, specify the --help flag to the configure
-program.
- The Berkeley DB specific options are as follows:
- The system libraries with which you are loading the db_dump185
-utility must already contain the Berkeley DB 1.85 library routines for this to
-work, as the Berkeley DB distribution does not include them. If you are using
-a non-standard library for the Berkeley DB 1.85 library routines, you will have
-to change the Makefile that the configuration step creates to load the
-db_dump185 utility with that library.
-
-
- Berkeley DB can be configured to build either a static or a dynamic library,
-but not both at once. You should not attempt to build both library
-types in the same directory, as they have incompatible object file
-formats. To build both static and dynamic libraries, create two
-separate build directories, and configure and build them separately.
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/flags.html b/bdb/docs/ref/build_unix/flags.html
deleted file mode 100644
index 5b70b3d8d64..00000000000
--- a/bdb/docs/ref/build_unix/flags.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- You can specify compiler and/or compile and load time flags by using
-environment variables during Berkeley DB configuration. For example, if you
-want to use a specific compiler, specify the CC environment variable
-before running configure:
- Using anything other than the native compiler will almost certainly mean
-that you'll want to check the flags specified to the compiler and
-loader, too.
- To specify debugging and optimization options for the C compiler,
-use the CFLAGS environment variable:
- To specify header file search directories and other miscellaneous options
-for the C preprocessor and compiler, use the CPPFLAGS environment variable:
- To specify debugging and optimization options for the C++ compiler,
-use the CXXFLAGS environment variable:
- To specify miscellaneous options or additional library directories for
-the linker, use the LDFLAGS environment variable:
- If you want to specify additional libraries, set the LIBS environment
-variable before running configure. For example:
- would specify two additional libraries to load, "posix" and "socket".
- Make sure that you prepend -L to any library directory names and that you
-prepend -I to any include file directory names! Also, if the arguments
-you specify contain blank or tab characters, be sure to quote them as
-shown above, i.e. with single or double quotes around the values you're
-specifying for LIBS.
- The env command is available on most systems, and simply sets one or more
-environment variables before running a command. If the env command is
-not available to you, you can set the environment variables in your shell
-before running configure. For example, in sh or ksh, you could do:
- and in csh or tcsh, you could do:
- See your command shell's manual page for further information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/freebsd.html b/bdb/docs/ref/build_unix/freebsd.html
deleted file mode 100644
index 3d3ff81161c..00000000000
--- a/bdb/docs/ref/build_unix/freebsd.html
+++ /dev/null
@@ -1,57 +0,0 @@
-
-
-
-
-
- Special compile-time flags are required when compiling threaded
-applications on FreeBSD. If you are compiling a threaded application,
-you must compile with the _THREAD_SAFE and -pthread flags:
- The Berkeley DB library will automatically build with the correct options.
- There is a known bug in the XDR implementation in the FreeBSD C library,
-from Version 2.2 up to version 4.0-RELEASE, that causes certain sized
-messages to fail and return a zero-filled reply to the client. A bug
-report (#16028) has been filed with FreeBSD. The following patch is the
-FreeBSD fix:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/hpux.html b/bdb/docs/ref/build_unix/hpux.html
deleted file mode 100644
index 3fc50d73cc9..00000000000
--- a/bdb/docs/ref/build_unix/hpux.html
+++ /dev/null
@@ -1,89 +0,0 @@
-
-
-
-
-
- The shmget(2) interfaces are not always used on HP-UX, even
-though they exist, as anonymous memory allocated using shmget(2)
-cannot be used to store the standard HP-UX msemaphore semaphores. For
-this reason, it may not be possible to specify the DB_SYSTEM_MEM
-flag on some versions of HP-UX. (We have only seen this problem on HP-UX
-10.XX, so the simplest workaround may be to upgrade your HP-UX release.)
- It is not possible to store the standard HP-UX msemaphore semaphores in
-memory returned by malloc(3) in some versions of HP-UX. For
-this reason, it may not be possible to specify both the DB_PRIVATE
-and DB_THREAD flags on some versions of HP-UX. (We have only seen
-this problem on HP-UX 10.XX, so the simplest workaround may be to upgrade
-your HP-UX release.)
- Some HP-UX system include files redefine "open" when big-file support (the
-HAVE_FILE_OFFSET_BITS and _FILE_OFFSET_BITS #defines) is enabled. This
-causes problems when compiling for C++, where "open" is a legal
-identifier, used in the Berkeley DB C++ API. For this reason, we automatically
-turn off big-file support when Berkeley DB is configured with a C++ API. This
-should not be a problem for applications unless there is a need to create
-databases larger than 2GB.
- Special compile-time flags are required when compiling threaded
-applications on HP-UX. If you are compiling a threaded application, you
-must compile with the _REENTRANT flag:
- The Berkeley DB library will automatically build with the correct options.
- Due to the constraints of the PA-RISC memory architecture, HP-UX does not
-allow a process to map a file into its address space multiple times.
-For this reason, each Berkeley DB environment may be opened only once by a
-process on HP-UX, i.e., calls to DBENV->open will fail if the
-specified Berkeley DB environment has been opened and not subsequently closed.
- We believe this is an error in the HP-UX include files, but we don't
-really understand it. The only workaround we have found is to add
--D__STDC_EXT__ to the C preprocessor defines as part of compilation.
- This problem happens when HP-UX has been configured to use pthread mutex
-locking and an attempt is made to call Berkeley DB using the Tcl or Perl APIs. We
-have never found any way to fix this problem as part of the Berkeley DB build
-process. To work around the problem, rebuild tclsh or perl and modify its build
-process to explicitly link it against the HP-UX pthread library (currently
-/usr/lib/libpthread.a).
- By default, some versions of HP-UX ignore the dynamic library search path
-specified by the SHLIB_PATH environment variable. To work around this, specify
-the "+s" flag to ld when linking, or run
- on the executable that is not working.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/install.html b/bdb/docs/ref/build_unix/install.html
deleted file mode 100644
index 7beb6f705f3..00000000000
--- a/bdb/docs/ref/build_unix/install.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- Berkeley DB installs the following files into the following locations, with the
-following default values:
- With one exception, this follows the GNU Autoconf and GNU Coding
-Standards installation guidelines, please see that documentation for
-more information and rationale.
- The single exception is the Berkeley DB documentation. The Berkeley DB
-documentation is provided in HTML format, not in UNIX-style man or GNU
-info format. For this reason, Berkeley DB configuration does not support
---infodir or --mandir. To change the default
-installation location for the Berkeley DB documentation, modify the Makefile
-variable, docdir.
- To move the entire installation tree to somewhere besides
-/usr/local, change the value of prefix.
- To move the binaries and libraries to a different location, change the
-value of exec_prefix. The values of includedir and
-libdir may be similarly changed.
- Any of these values except for docdir may be set as part
-of configuration:
- Any of these values, including docdir, may be changed when doing
-the install itself:
- The Berkeley DB installation process will attempt to create any directories that
-do not already exist on the system.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/intro.html b/bdb/docs/ref/build_unix/intro.html
deleted file mode 100644
index b2c0d613bfd..00000000000
--- a/bdb/docs/ref/build_unix/intro.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- The Berkeley DB distribution builds up to four separate libraries: the base C
-API Berkeley DB library and the optional C++, Java and Tcl API libraries. For
-portability reasons each library is standalone and contains the full Berkeley DB
-support necessary to build applications, that is, the C++ API Berkeley DB
-library does not require any other Berkeley DB libraries to build and run C++
-applications.
- The Berkeley DB distribution uses the Free Software Foundation's
-autoconf and
-libtool
-tools to build on UNIX platforms. In general, the standard configuration
-and installation options for these tools apply to the Berkeley DB distribution.
- To perform the default UNIX build of Berkeley DB, first change to the
-build_unix directory, and then enter the following two commands:
- This will build the Berkeley DB library.
- To install the Berkeley DB library, enter:
- To rebuild Berkeley DB, enter:
- If you change your mind about how Berkeley DB is to be configured, you must start
-from scratch by entering:
- To build multiple UNIX versions of Berkeley DB in the same source tree, create a
-new directory at the same level as the build_unix directory, and then
-configure and build in that directory:
- If you have trouble with any of these commands, please send email to the
-addresses found in the Sleepycat Software contact information. In that
-email, please provide a complete copy of the commands that you entered
-and any output, along with a copy of any config.log or
-config.cache files created during configuration.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/irix.html b/bdb/docs/ref/build_unix/irix.html
deleted file mode 100644
index af31b6e6811..00000000000
--- a/bdb/docs/ref/build_unix/irix.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- Special compile-time flags are required when compiling threaded
-applications on IRIX. If you are compiling a threaded application, you
-must compile with the _SGI_MP_SOURCE flag:
- The Berkeley DB library will automatically build with the correct options.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/linux.html b/bdb/docs/ref/build_unix/linux.html
deleted file mode 100644
index b6e2b93fb14..00000000000
--- a/bdb/docs/ref/build_unix/linux.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- Special compile-time flags are required when compiling threaded
-applications on Linux. If you are compiling a threaded application, you
-must compile with the _REENTRANT flag:
- The Berkeley DB library will automatically build with the correct options.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/notes.html b/bdb/docs/ref/build_unix/notes.html
deleted file mode 100644
index dcb975e3c9e..00000000000
--- a/bdb/docs/ref/build_unix/notes.html
+++ /dev/null
@@ -1,138 +0,0 @@
-
-
-
-
-
- On systems where they're available (e.g., HP-UX, Solaris), Berkeley DB uses
-64-bit integral types. As far as we can tell, some versions of gcc
-don't support these types. The simplest workaround is to reconfigure
-Berkeley DB using the --disable-bigfile configuration option, and then rebuild.
- We believe there are some severe bugs in the implementation of exceptions
-for some gcc compilers. Exceptions require some interaction between
-compiler, assembler, runtime libraries, and we're not sure exactly what
-is at fault, but one failing combination is gcc 2.7.2.3 running on SuSE
-Linux 6.0. The problem on this system can be seen with a rather simple
-test case of an exception thrown from a shared library and caught in the
-main program.
- A variation of this problem seems to occur on AIX, although we believe it
-does not necessarily involve shared libraries on that platform.
- If you see a trap that occurs when an exception might be thrown by the DB
-runtime, we suggest that you use static libraries instead of dynamic
-(shared) libraries. See the documentation for configuration. If this
-doesn't work, and you have a choice of compilers, try using a more recent
-gcc or a non-gcc based compiler to build Berkeley DB.
- Finally, you can disable the use of exceptions in the C++ runtime for
-Berkeley DB by using the DB_CXX_NO_EXCEPTIONS flag with
-db_env_create or db_create. When this flag is on, all
-C++ methods fail by returning an error code rather than throwing an
-exception.
- I get error messages that mutex (e.g., pthread_mutex_XXX or
-mutex_XXX) functions are undefined when linking applications with Berkeley DB.
- On some architectures, the Berkeley DB library uses the ISO POSIX standard
-pthreads and UNIX International (UI) threads interfaces for underlying
-mutex support, e.g., Solaris and HP-UX. You can specify compilers,
-compiler flags or link with the appropriate thread library when loading
-your application, to resolve the undefined references:
- See the appropriate architecture-specific Reference Guide pages for more
-information.
- On systems where more than one type of mutex is available, it may be
-necessary for applications to use the same threads package from which
-Berkeley DB draws its mutexes, e.g., if Berkeley DB was built to use the POSIX
-pthreads mutex calls for mutex support, the application may need to be
-written to use the POSIX pthreads interfaces for its threading model.
-While this is only conjecture at this time and we know of no systems that
-actually have this requirement, it's not unlikely that some exist.
- In a few cases, Berkeley DB can be configured to use specific underlying mutex
-interfaces. You can use the --enable-posixmutexes and
---enable-uimutexes configuration options to specify the POSIX and Unix
-International (UI) threads packages. This should not, however, be
-necessary in most cases.
- In some cases, it is vitally important to make sure that you load
-the correct library. For example, on Solaris systems, there are POSIX
-pthread interfaces in the C library, and so applications can link Berkeley DB
-using only C library and not see any undefined symbols. However, the C
-library POSIX pthread mutex support is insufficient for Berkeley DB and Berkeley DB
-cannot detect that fact. Similar errors can arise when applications
-(e.g., tclsh) use dlopen to dynamically load Berkeley DB as a library.
- If you are seeing problems in this area after you've confirmed that you're
-linking with the correct libraries, there are two other things you can
-try. First, if your platform supports inter-library dependencies, we
-recommend that you change the Berkeley DB Makefile to specify the appropriate
-threads library when creating the Berkeley DB dynamic library, as an
-inter-library dependency. Second, if your application is using dlopen to
-dynamically load Berkeley DB, specify the appropriate thread library on the link
-line when you load the application itself.
- Berkeley DB handles should not be shared across process forks, each forked
-child should acquire its own Berkeley DB handles.
- For performance reasons, Berkeley DB does not write the unused portions of
-database pages or fill in unused structure fields. To turn off these
-errors when running software analysis tools, build with the
---enable-umrw configuration option.
- The Berkeley DB architecture does not support placing the shared memory regions
-on remote filesystems, e.g., the Network File System (NFS) or the Andrew
-File System (AFS). For this reason, the shared memory regions (normally
-located in the database home directory) must reside on a local filesystem.
-See Shared Memory Regions for more
-information.
- With respect to running the test suite, always check to make sure that
-TESTDIR is not on a remote mounted filesystem.
- The db_dump185 utility is the utility that supports conversion
-of Berkeley DB 1.85 and earlier databases to current database formats. If
-the errors look something like:
- it means that the Berkeley DB 1.85 code was not found in the standard
-libraries. To build db_dump185, the Berkeley DB version 1.85 code
-must have already been built and installed on the system. If the Berkeley DB
-1.85 header file is not found in a standard place, or the library is
-not part of the standard libraries used for loading, you will need to
-edit your Makefile, and change the lines:
- So that the system Berkeley DB 1.85 header file and library are found, e.g.,
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/osf1.html b/bdb/docs/ref/build_unix/osf1.html
deleted file mode 100644
index 42ac8e767ef..00000000000
--- a/bdb/docs/ref/build_unix/osf1.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- Special compile-time flags are required when compiling threaded
-applications on OSF/1. If you are compiling a threaded application, you
-must compile with the _REENTRANT flag:
- The Berkeley DB library will automatically build with the correct options.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/qnx.html b/bdb/docs/ref/build_unix/qnx.html
deleted file mode 100644
index 29c90dc98cb..00000000000
--- a/bdb/docs/ref/build_unix/qnx.html
+++ /dev/null
@@ -1,58 +0,0 @@
-
-
-
-
-
- Berkeley DB has been ported to the QNX Neutrino technology which is commonly
-referred to as QNX RTP (Real-Time Platform). Berkeley DB has not been
-ported to earlier versions of QNX, such as QNX 4.25.
- QNX requires the use of the POSIX shm_open(2) and
-shm_unlink(2) calls for shared memory regions that will later
-be mapped into memory using mmap(2). QNX's implementation
-of the shared memory functions requires that the name given must begin
-with a slash, and that no other slash may appear in the name.
- In order to comply with those requirements and allow relative pathnames
-to find the same environment, Berkeley DB uses only the last component of the
-home directory path and the name of the shared memory file, separated
-by a colon, as the name specified to the shared memory functions. For
-example, if an application specifies a home directory of
-/home/db/DB_DIR, Berkeley DB will use /DB_DIR:__db.001 as
-the name for the shared memory area argument to shm_open(2).
- The impact of this decision is that the last component of all
-environment home directory pathnames on QNX must be unique with respect
-to each other. Additionally, Berkeley DB requires that environments use home
-directories for QNX in order to generate a reasonable entry in the
-shared memory area.
- QNX requires that files mapped with mmap(2) be opened using
-shm_open(2). There are other places in addition to the
-environment shared memory regions, where Berkeley DB tries to memory map files
-if it can.
- The memory pool subsystem normally attempts to use mmap(2)
-even when using private memory, as indicated by the DB_PRIVATE
-flag to DBENV->open. In the case of QNX, if an application is
-using private memory, Berkeley DB will not attempt to map the memory and will
-instead use the local cache.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/sco.html b/bdb/docs/ref/build_unix/sco.html
deleted file mode 100644
index dda8e6d1d01..00000000000
--- a/bdb/docs/ref/build_unix/sco.html
+++ /dev/null
@@ -1,29 +0,0 @@
-
-
-
-
-
- We suspect gcc or the runtime loader may have a bug, but we haven't
-tracked it down. If you want to use gcc, we suggest building static
-libraries.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/shlib.html b/bdb/docs/ref/build_unix/shlib.html
deleted file mode 100644
index 2819651cd1d..00000000000
--- a/bdb/docs/ref/build_unix/shlib.html
+++ /dev/null
@@ -1,94 +0,0 @@
-
-
-
-
-
- Warning: the following information is intended to be generic and
-is likely to be correct for most UNIX systems. Unfortunately, dynamic
-shared libraries are not standard between UNIX systems, so there may be
-information here that is not correct for your system. If you have
-problems, consult your compiler and linker manual pages or your system
-administrator.
- The Berkeley DB dynamic shared libraries are created with the name
-libdb-major.minor.so, where major is the major
-version number and minor is the minor version number. Other
-shared libraries are created if Java and Tcl support are enabled,
-specifically libdb_java-major.minor.so and
-libdb_tcl-major.minor.so.
- On most UNIX systems, when any shared library is created, the linker
-stamps it with a "SONAME". In the case of Berkeley DB, the SONAME is
-libdb-major.minor.so. It is important to realize that
-applications linked against a shared library remember the SONAMEs of the
-libraries they use and not the underlying names in the filesystem.
- When the Berkeley DB shared library is installed, links are created in the
-install lib directory so that libdb-major.minor.so,
-libdb-major.so and libdb.so all reference the same library. This
-library will have an SONAME of libdb-major.minor.so.
- Any previous versions of the Berkeley DB libraries that are present in the
-install directory (such as libdb-2.7.so or libdb-2.so) are left unchanged.
-(Removing or moving old shared libraries is one drastic way to identify
-applications that have been linked against those vintage releases.)
- Once you have installed the Berkeley DB libraries, unless they are installed in
-a directory where the linker normally looks for shared libraries, you will
-need to specify the installation directory as part of compiling and
-linking against Berkeley DB. Consult your system manuals or system
-administrator for ways to specify a shared library directory when
-compiling and linking applications with the Berkeley DB libraries. Many systems
-support environment variables (e.g., LD_LIBRARY_PATH, LD_RUN_PATH) ), or
-system configuration files (e.g., /etc/ld.so.conf) for this purpose.
- Warning: some UNIX installations may have an already existing
-/usr/lib/libdb.so, and this library may be an incompatible
-version of Berkeley DB.
- We recommend that applications link against libdb.so (e.g., using -ldb).
-Even though the linker uses the file named libdb.so, the executable file
-for the application remembers the library's SONAME
-(libdb-major.minor.so). This has the effect of marking
-the applications with the versions they need at link time. Because
-applications locate their needed SONAMEs when they are executed, all
-previously linked applications will continue to run using the library they
-were linked with, even when a new version of Berkeley DB is installed and the
-file libdb.so is replaced with a new version.
- Applications that know they are using features specific to a particular
-Berkeley DB release can be linked to that release. For example, an application
-wanting to link to Berkeley DB major release "3" can link using -ldb-3, and
-applications that know about a particular minor release number can specify
-both major and minor release numbers, for example, -ldb-3.5.
- If you want to link with Berkeley DB before performing library installation,
-the "make" command will have created a shared library object in the
-.libs subdirectory of the build directory, such as
-build_unix/.libs/libdb-major.minor.so. If you want to link a
-file against this library, with, for example, a major number of "3" and
-a minor number of "5", you should be able to do something like:
- where BUILD_DIRECTORY is the full directory path to the directory
-where you built Berkeley DB.
- The libtool program (which is configured in the build_unix directory) can
-be used to set the shared library path and run a program. For example,
- runs the gdb debugger on the db_dump utility after setting the appropriate
-paths. Libtool may not know what to do with arbitrary commands (it is
-hardwired to recognize "gdb" and some other commands). If it complains
-the mode argument will usually resolve the problem:
- On most systems, using libtool in this way is exactly equivalent to
-setting the LD_LIBRARY_PATH environment variable and then executing the
-program. On other systems, using libtool has the virtue of knowing about
-any other details on systems that don't behave in this typical way.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/solaris.html b/bdb/docs/ref/build_unix/solaris.html
deleted file mode 100644
index 8239537a825..00000000000
--- a/bdb/docs/ref/build_unix/solaris.html
+++ /dev/null
@@ -1,90 +0,0 @@
-
-
-
-
-
- Special compile-time flags and additional libraries are required when
-compiling threaded applications on Solaris. If you are compiling a
-threaded application, you must compile with the D_REENTRANT flag and link
-with the libpthread.a or libthread.a libraries:
- The Berkeley DB library will automatically build with the correct options.
- On some versions of Solaris, there is a cc executable in the user's path,
-but all it does is display an error message and fail:
- As Berkeley DB always uses the native compiler in preference to gcc, this is a
-fatal error. If the error message you're seeing is:
- then this may be the problem you're seeing. The simplest workaround is
-to set your CC environment variable to the system compiler, e.g.:
- and reconfigure.
- If you are using the --configure-cxx option, you may also want to specify
-a C++ compiler, e.g.:
- This is a known bug in Solaris 2.5 and it is fixed by Sun patch 103187-25.
- Solaris 7 contains a bug in the threading libraries (-lpthread, -lthread)
-which causes the wrong version of the pwrite routine to be linked into
-the application if the thread library is linked in after the the C
-library. The result will be that the pwrite function is called rather
-than the pwrite64. To work around the problem, use an explicit link order
-when creating your application.
- Sun Microsystems is tracking this problem with Bug Id's 4291109 and 4267207,
-and patch 106980-09 to Solaris 7 fixes the problem.
- The Solaris 8 system include files redefine "open" when big-file support (the
-HAVE_FILE_OFFSET_BITS and _FILE_OFFSET_BITS #defines) is enabled. This
-causes problems when compiling for C++, where "open" is a legal
-identifier, used in the Berkeley DB C++ API. For this reason, we automatically
-turn off big-file support when Berkeley DB is configured with a C++ API. This
-should not be a problem for applications unless there is a need to create
-databases larger than 2GB.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/sunos.html b/bdb/docs/ref/build_unix/sunos.html
deleted file mode 100644
index cecccaefb94..00000000000
--- a/bdb/docs/ref/build_unix/sunos.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- The shmget(2) interfaces are not used on SunOS releases prior
-to 5.0, even though they apparently exist, as the distributed include
-files did not allow them to be compiled. For this reason, it will not be
-possible to specify the DB_SYSTEM_MEM flag those versions of
-SunOS.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/test.html b/bdb/docs/ref/build_unix/test.html
deleted file mode 100644
index 9ae398980f6..00000000000
--- a/bdb/docs/ref/build_unix/test.html
+++ /dev/null
@@ -1,49 +0,0 @@
-
-
-
-
-
- The Berkeley DB test suite is built if you specify --enable-test as an
-argument when configuring Berkeley DB.
- Before running the tests for the first time, you may need to edit the
-include.tcl file in your build directory. The Berkeley DB
-configuration assumes you intend to use the version of the tclsh utility
-included in the Tcl installation with which Berkeley DB was configured to run
-the test suite, and further assumes that the test suite will be run with
-the libraries pre-built in the Berkeley DB build directory. If either of these
-assumptions are incorrect, you will need to edit the include.tcl
-file and change the line that reads:
- to correctly specify the full path to the version of tclsh with which you
-are going to run the test suite. You may also need to change the line
-that reads:
- to correctly specify the path from the directory where you are running
-the test suite to the location of the Berkeley DB Tcl API library you built.
-It may not be necessary that this be a full path if you have configured
-your system's dynamic shared library mechanisms to search the directory
-where you built or installed the Tcl library.
- All Berkeley DB tests are run from within tclsh. After starting tclsh,
-you must source the file test.tcl in the test directory. For
-example, if you built in the build_unix directory of the
-distribution, this would be done using the command:
- Once you have executed that command and the "%" prompt has returned
-without errors, you are ready to run tests in the test suite.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_unix/ultrix.html b/bdb/docs/ref/build_unix/ultrix.html
deleted file mode 100644
index e71946c8825..00000000000
--- a/bdb/docs/ref/build_unix/ultrix.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- The mmap(2) interfaces are not used on Ultrix, even though
-they exist, as they are known to not work correctly.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_vxworks/faq.html b/bdb/docs/ref/build_vxworks/faq.html
deleted file mode 100644
index cea733d7fb2..00000000000
--- a/bdb/docs/ref/build_vxworks/faq.html
+++ /dev/null
@@ -1,85 +0,0 @@
-
-
-
-
-
- The test suite requires the Berkeley DB Tcl library. In turn, this library
-requires Tcl 8.1 or greater. In order to run the test suite, you would
-need to port Tcl 8.1 or greater to VxWorks. The Tcl shell included in
-windsh is not adequate for two reasons. First, it is based on
-Tcl 8.0. Second, it does not include the necessary Tcl components for
-adding a Tcl extension.
- All Berkeley DB features are available for VxWorks with the exception of the
-DB_TRUNCATE flag for DB->open. The underlying mechanism
-needed for that flag is not available consistently across different file
-systems for VxWorks.
- There are constraints using the dosFs file systems with Berkeley DB. Namely,
-you must configure your dosFs file system to support long file names if
-you are using Berkeley DB logging in your application. The VxWorks' dosFs
-1.0 file system, by default, uses the old MS-DOS 8.3 file naming
-constraints, restricting to 8 character file names with a 3 character
-extension. If you have configured with VxWorks' dosFs 2.0 you should
-be compatible with Windows FAT32 filesystems which supports long
-filenames.
- There is one dependency on specifics of file system drivers in the port
-of Berkeley DB to VxWorks. Berkeley DB synchronizes data using the FIOSYNC function
-to ioctl() (another option would have been to use the FIOFLUSH function
-instead). The FIOSYNC function was chosen because the NFS client driver,
-nfsDrv, only supports it and doesn't support FIOFLUSH. All local file
-systems, as of VxWorks 5.4, support FIOSYNC with the exception of
-rt11fsLib, which only supports FIOFLUSH. To use rt11fsLib, you will need
-to modify the os/os_fsync.c file to use the FIOFLUSH function; note that
-rt11fsLib cannot work with NFS clients.
- During the course of our internal testing we came across two problems
-with the dosFs 2.0 file system that warranted patches from Wind River Systems.
-You should ask Wind River Systems for the patches to these
-problems if you encounter them.
- The first problem is that files will seem to disappear. You should
-look at SPR 31480 in the Wind River Systems' Support pages for
-a more detailed description of this problem.
- The second problem is a semaphore deadlock within the dosFs file system
-code. Looking at a stack trace via CrossWind, you will see two or more of
-your application's tasks waiting in semaphore code within dosFs. The patch
-for this problem is under SPR 33221 at Wind River Systems.
- The Target Server File System (TSFS) uses the netDrv driver. This driver
-does not support any ioctl that allows flushing to the disk and therefore
-cannot be used with Berkeley DB.
- The utility programs, in their Unix-style form, are not ported to VxWorks.
-The reasoning is the utility programs are essentially wrappers for the
-specific Berkeley DB interface they call. Their interface and generic model
-are not the appropriate paradigm for VxWorks. It is most likely that
-specific applications will want to spawn tasks that call the appropriate
-Berkeley DB function to perform the actions of some utility programs, using
-VxWorks native functions. For example, an application that spawns several
-tasks that all may operate on the same database would also want to spawn
-a task that calls lock_detect for deadlock detection, but specific
-to the environment used for that application.
- Mutexes inside of Berkeley DB use the basic binary semaphores in VxWorks. The
-mutexes are created using the FIFO queue type.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_vxworks/intro.html b/bdb/docs/ref/build_vxworks/intro.html
deleted file mode 100644
index 593b8a1e64c..00000000000
--- a/bdb/docs/ref/build_vxworks/intro.html
+++ /dev/null
@@ -1,86 +0,0 @@
-
-
-
-
-
- The build_vxworks directory in the Berkeley DB distribution contains a workspace
-and project files for Tornado 2.0.
- Open the workspace Berkeley DB.wsp. The list of projects
-in this workspace will be shown. These projects were created for
-the x86 BSP for VxWorks.
- The remainder of this document assumes you already have a
-VxWorks target and a target server, both up and running.
- First, you'll need to set the include directories.
-To do this, go to the Builds tab for the workspace.
-Open up Berkeley DB Builds. You will see several different
-builds, containing different configurations. All of the projects
-in the Berkeley DB workspace are created to be downloadable applications.
- You will have to add a new build specification if you are using a
-different BSP or wish to customize further. For instance, if you have
-the Power PC (PPC) BSP, you will need to add a new build for the PPC tool
-chain. To do so, select the "Builds" tab and then select the Berkeley DB
-project name and right click. Choose the New Build...
-selection and create the new build target. For your new build target,
-you will need to decide if you want it configured to support RPC and
-whether it should be built for debugging. See the properties of the
-Pentium builds for how to configure for each case. After you have added
-this build you still need to correctly configure the include directories
-as described below.
- Select the build you are interested in and right click. Choose the
-Properties... selection. At this point, a tabbed dialogue
-should appear. In this new window, choose the C/C++ compiler
-tab. In the edit box, you need to modify the full pathname of the
-build_vxworks subdirectory of Berkeley DB, followed by the full
-pathname of the include subdirectory of Berkeley DB. Then click
-OK.
- If the architecture for this new build has the most significant byte
-first, you will also need to edit the db_config.h file in
-the build directory and define WORDS_BIGENDIAN.
- To build and download the Berkeley DB downloadable application for the first time
-requires several steps:
- You will need to repeat this procedure for
-all builds you are interested in building, as well as for
-all of the example project builds you wish to run.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_vxworks/notes.html b/bdb/docs/ref/build_vxworks/notes.html
deleted file mode 100644
index 83de255119b..00000000000
--- a/bdb/docs/ref/build_vxworks/notes.html
+++ /dev/null
@@ -1,56 +0,0 @@
-
-
-
-
-
- Berkeley DB currently disallows the DB_TRUNC flag to DB->open.
-The operations this flag represent are not fully supported under
-VxWorks 5.4.
- The memory on VxWorks is always resident and fully shared among all tasks
-running on the target. For this reason, the DB_SYSTEM_MEM flag
-is implied for any application that does not specify the
-DB_PRIVATE flag. Additionally, applications must use a
-segment ID to ensure different applications do not overwrite each other's
-database environments.
-See the DBENV->set_shm_key function for more information.
-Also, the DB_LOCKDOWN flag has no effect.
- The DB->sync function is implemented using an ioctl call into the
-file system driver with the FIOSYNC command. Most, but not all, file
-system drivers support this call. Berkeley DB requires the use of a file system
-supporting FIOSYNC.
- Each example program can be downloaded and run by calling the function
-equivalent to the example's name. You may have to edit the pathname to
-the environments and database names in the examples' sources. The
-examples included are:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_win/faq.html b/bdb/docs/ref/build_win/faq.html
deleted file mode 100644
index 2c185b6daa2..00000000000
--- a/bdb/docs/ref/build_win/faq.html
+++ /dev/null
@@ -1,49 +0,0 @@
-
-
-
-
-
- You should be using the "Debug Multithreaded DLL" compiler option in
-your application when you link with the
-build_win32/Debug/libdb32d.lib library (this .lib file
-is actually a stub for libdb32d.DLL). To check this
-setting in Visual C++, choose the "Project/Settings" menu item, and
-under the tab marked "C/C++", select "Code Generation" and see the box
-marked "Use runtime library". This should be set to "Debug
-Multithreaded DLL". If your application is linked against the static
-library, build_win32/Debug/libdb32sd.lib, then you
-will want to set "Use runtime library" to "Debug Multithreaded".
- Setting this option incorrectly can cause multiple versions of the
-standard libraries to be linked into your application (one on behalf
-of your application, and one on behalf of the Berkeley DB library). That
-violates assumptions made by these libraries, and traps can result.
- Berkeley DB does not use MFC at all. It does however, call malloc and free and
-other facilities provided by the Microsoft C runtime library. We've found
-in our work that many applications and libraries are built assuming MFC,
-and specifying this for Berkeley DB solves various interoperation issues, and
-guarantees that the right runtime libraries are selected. Note that since
-we do not use MFC facilities, the MFC library DLL is not marked as a
-dependency for libdb.dll, but the appropriate Microsoft C runtime is.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_win/intro.html b/bdb/docs/ref/build_win/intro.html
deleted file mode 100644
index 6f5e0d4bbf4..00000000000
--- a/bdb/docs/ref/build_win/intro.html
+++ /dev/null
@@ -1,143 +0,0 @@
-
-
-
-
-
- The build_win32 directory in the Berkeley DB distribution contains project files
-for both MSVC 5.0 and 6.0:
- These project files can be used to build Berkeley DB for any Win32 platform:
-Windows 2000, Windows NT, Windows 98 and Windows 95.
- Open the file Berkeley_DB.dsw. You will be told that the project
-was generated by a previous version of Developer Studio, and asked if you
-want to convert the project. Select Yes, and all projects will be
-converted. Then continue on with the instructions for building with
-Visual C++ 5.0.
- Note that when you build a release version, you may receive a warning
-about an unknown compiler option /Ob2. This is apparently a
-flaw in the project conversion for Visual C++ and can be ignored.
- Each release of Berkeley DB is built and tested with this procedure using
-Microsoft Visual C++ 6.0, Standard Edition.
- Open the file Berkeley_DB.dsw. This workspace includes a number
-of subprojects needed to build Berkeley DB.
- First, you'll need to set the include directories. To do this, select
-Options... from the Tools pull-down menu. At this
-point, a tabbed dialogue should appear. In this new window, choose the
-Directories tab. For the Platform, select
-Win32 and for Show directories for select
-Include files. Below these options in the list of directories,
-you should add two directories: the full pathname of the
-build_win32 subdirectory of Berkeley DB, followed by the full
-pathname of the include subdirectory of Berkeley DB. Then click OK.
- Then, select Active Project Configuration under the
-Build pull-down menu. For a debug version of the libraries,
-tools and examples, select db_buildall - Win32 Debug.
-Results from this build are put into build_win32/Debug.
-For a release version, select db_buildall - Win32 Release;
-results are put into build_win32/Release.
-For a debug version that has all tools and examples built with
-static libraries, select db_buildall - Win32 Debug Static;
-results are put into build_win32/Debug_static.
-For a release version of the same,
-select db_buildall - Win32 Release Static;
-results are put into build_win32/Release_static.
-Finally, to build, select Build db_buildall.exe under the
-Build pull-down menu.
- When building your application, you should normally use compile options
-"debug multithreaded dll" and link against
-build_win32/Debug/libdb32d.lib. If you want
-to link against a static (non-DLL) version of the library, use the
-"debug multithreaded" compile options and link against
-build_win32/Debug_static/libdb32sd.lib. You can
-also build using a release version of the libraries and tools, which will be
-placed in build_win32/Release/libdb32.lib.
-The static version will be in
-build_win32/Release_static/libdb32s.lib.
- Each release of Berkeley DB is maintained, built and tested using Microsoft
-Visual C++ 5.0 and 6.0.
- C++ support is built automatically on Win32.
- Java support is not built automatically. The following instructions
-assume you have installed the Sun Java Development Kit in
-d:/java. Of course, if you've installed elsewhere, or have
-different Java software, you will need to adjust the pathnames
-accordingly. First, use the instructions above for Visual C++ 5.0 or 6.0
-to open the Tools/Options tabbed dialog for adding include directories.
-In addition to the directories specified above, add
-d:/java/include and d:/java/include/win32. These are
-the directories needed when including jni.h. Now, before
-clicking OK, under Show directories for, choose
-Executable files. Add d:/java/bin. That directory
-is needed to find javac. Now select OK.
- Select Active Project Configuration under the
-Build pull-down menu. Choose db_java - Win32
-Release. To build, select Build
-libdb_java32.dll under the Build pull-down
-menu. This builds the Java support library for Berkeley DB and compiles all
-the java files, placing the class files in the java/classes
-subdirectory of Berkeley DB. Set your environment variable CLASSPATH to
-include this directory, your environment variable PATH to include the
-build_win32/Release subdirectory, and as a test, try running
-the command:
- Tcl support is not built automatically. See
-Loading Berkeley DB with Tcl for information
-on sites from which you can download Tcl and which Tcl versions are
-compatible with Berkeley DB.
- The Tcl library must be built as the same build type as the Berkeley DB
-library (both Release or both Debug). We have found that the binary
-release of Tcl can be used with the Release configuration of Berkeley DB, but
-for the Debug configuration, you will need to need to build Tcl from
-sources. Before building Tcl, you will need to modify its makefile to
-make sure you are building a debug version, including thread support.
-This is because the set of DLLs linked into the Tcl executable must
-match the corresponding set of DLLs used by Berkeley DB.
- These notes assume Tcl is installed as d:/tcl, but you can
-change that if you wish. If you run using a different version of Tcl
-than the one currently being used by Sleepycat Software, you will need
-to change the name of the Tcl library used in the build (e.g.,
-tcl83d.lib) to the appropriate name. See
-Projects->Settings->Link in the db_tcl subproject.
- Use the instructions above for
-Visual C++ 5.0 or 6.0 to open the Tools/Options tabbed dialog
-for adding include directories. In addition to the directories specified
-above, add d:/tcl/include. This is the directory that contains
-tcl.h.
-Then, in that same dialog, show directories for "Library Files".
-Add d:/tcl/lib (or whatever directory contains
-tcl83d.lib in your distribution) to the list. Now select OK.
- Select Active Project Configuration under the
-Build pull-down menu. Choose db_tcl - Win32
-Release. To build, select Build
-libdb_tcl32.dll under the Build pull-down
-menu. This builds the Tcl support library for Berkeley DB, placing the result
-into build_win32/Release/libdb_tcl32.dll.
-Selecting an Active Configuration of db_tcl - Win32 Debug
-will build a debug version, placing the result into
-build_win32/Debug/libdb_tcl32d.dll.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_win/notes.html b/bdb/docs/ref/build_win/notes.html
deleted file mode 100644
index 483b101ecc2..00000000000
--- a/bdb/docs/ref/build_win/notes.html
+++ /dev/null
@@ -1,56 +0,0 @@
-
-
-
-
-
- It would be possible to construct a set of security attributes to pass to
-CreateFile that accurately represents the mode. In the worst
-case, this would involve looking up user and all group names and creating
-an entry for each. Alternatively, we could call the _chmod
-(partial emulation) function after file creation, although this leaves us
-with an obvious race.
- Practically speaking, however, these efforts would be largely meaningless
-on FAT, the most common file system, which only has a "readable" and
-"writeable" flag, applying to all users.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/build_win/test.html b/bdb/docs/ref/build_win/test.html
deleted file mode 100644
index e3230ca84a4..00000000000
--- a/bdb/docs/ref/build_win/test.html
+++ /dev/null
@@ -1,77 +0,0 @@
-
-
-
-
-
- To build the test suite on Win32 platforms you will need to configure
-Tcl support. You will also need sufficient main memory and disk.
-Something around 100MB of disk will be sufficient. For memory, 32MB is
-too small, we recommend at least 64MB.
- There exist bugs in some versions of Tcl that may cause the test suite
-to hang on Windows/NT 4.0. Tcl version 8.4 (currently available as an
-alpha release) has fixed the problem, or there are patches available
-for Tcl 8.3.2 (see bug #119188 in the Tcl SourceForge database). Note
-that if you want to run the test suite against a Debug version of Berkeley DB,
-you need to build a debug version of Tcl. This involves building Tcl
-from its source.
- To build, perform the following steps. Note that steps #1, #4 and #5
-are part of the normal build process for building Berkeley DB; #2, #3 are part
-of including the Tcl API.
- Before running the tests for the first time, you must edit the file
-include.tcl in your build directory and change the line
-that reads:
- You will want to use the location of the tclsh program. For
-example, if Tcl is installed as d:/tcl, this line should be:
- Then, in a shell of your choice enter the following commands:
- You should get a "%" prompt.
- You should get a "%" prompt with no errors.
- You are now ready to run tests in the test suite, see
-Running the test suite for more
-information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/cam/intro.html b/bdb/docs/ref/cam/intro.html
deleted file mode 100644
index 7a02ea87f93..00000000000
--- a/bdb/docs/ref/cam/intro.html
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
-
-
-
- It is often desirable to have concurrent read-write access to a database
-when there is no need for full recoverability or transaction semantics.
-For this class of applications, Berkeley DB provides an interface supporting
-deadlock free, multiple-reader/single writer access to the database.
-This means that, at any instant in time, there may be either multiple
-readers accessing data or a single writer modifying data. The
-application is entirely unaware of which is happening, and Berkeley DB
-implements the necessary locking and blocking to ensure this behavior.
- In order to create Berkeley DB Concurrent Data Store applications, you must first initialize an
-environment by calling DBENV->open. You must specify the
-DB_INIT_CDB and DB_INIT_MPOOL flags to that interface.
-It is an error to specify any of the other DBENV->open subsystem
-or recovery configuration flags, e.g., DB_INIT_LOCK,
-DB_INIT_TXN or DB_RECOVER.
- All databases must, of course, be created in this environment, by using
-the db_create interface and specifying the correct environment
-as an argument.
- The Berkeley DB access method calls used to support concurrent access are
-unchanged from the normal access method calls, with one exception: the
-DB->cursor interface. In Berkeley DB Concurrent Data Store, each cursor must encapsulate
-the idea of being used for read-only access or for read-write access.
-There may only be one read-write cursor active at any one time. When your
-application creates a cursor, if that cursor will ever be used for
-writing, the DB_WRITECURSOR flag must be specified when the cursor
-is created.
- No deadlock detector needs to be run in a Berkeley DB Concurrent Data Store database environment.
- Only a single thread of control may write the database at a time. For
-this reason care must be taken to ensure that applications do not
-inadvertently block themselves causing the application to hang, unable
-to proceed. Some common mistakes include:
- Note that it is correct operation for two different threads of control
-(actual threads or processes) to have multiple read-write cursors open,
-or for one thread to issue a DB->put call while another thread
-has a read-write cursor open, and it is only a problem if these things
-are done within a single thread of control.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/debug/common.html b/bdb/docs/ref/debug/common.html
deleted file mode 100644
index 6374307f133..00000000000
--- a/bdb/docs/ref/debug/common.html
+++ /dev/null
@@ -1,109 +0,0 @@
-
-
-
-
-
- This page outlines some of the most common problems that people encounter
-and some suggested courses of action.
- Whenever you get a DB_LOCK_DEADLOCK return, you should:
- See Recoverability and deadlock
-avoidance for further information.
- Or, if the application is doing a large number of updates in a small
-database, turning off Btree splits may help (see DB_REVSPLITOFF
-for more information.)
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/debug/compile.html b/bdb/docs/ref/debug/compile.html
deleted file mode 100644
index 504d5d3ecd6..00000000000
--- a/bdb/docs/ref/debug/compile.html
+++ /dev/null
@@ -1,43 +0,0 @@
-
-
-
-
-
- There are two compile-time configuration options that assist in debugging
-Berkeley DB and Berkeley DB applications.
- In addition, when compiling Berkeley DB for use in run-time memory consistency
-checkers, in particular, programs that look for reads and writes of
-uninitialized memory, use --enable-diagnostic as an argument to configure.
-This guarantees that Berkeley DB will completely initialize allocated pages
-rather than only initializing the minimum necessary amount.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/debug/intro.html b/bdb/docs/ref/debug/intro.html
deleted file mode 100644
index 0ea0afcfb22..00000000000
--- a/bdb/docs/ref/debug/intro.html
+++ /dev/null
@@ -1,58 +0,0 @@
-
-
-
-
-
- As Berkeley DB is an embedded library, debugging applications that use Berkeley DB
-is both harder and easier than debugging a separate server. Debugging
-can be harder, because, when a problem arises, it is not always readily
-apparent whether the problem is in the application, in the database
-library, or is a result of an unexpected interaction between the two.
-Debugging can be easier, as it is easier to track down a problem when
-you can review a stack trace rather than deciphering inter-process
-communication messages. This chapter is intended to assist you in
-debugging applications and in reporting bugs to us in a manner such that
-we can provide you with the correct answer or fix as quickly as
-possible.
- When you encounter a problem, there are a few general actions you can
-take:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/debug/printlog.html b/bdb/docs/ref/debug/printlog.html
deleted file mode 100644
index e533a88d21c..00000000000
--- a/bdb/docs/ref/debug/printlog.html
+++ /dev/null
@@ -1,160 +0,0 @@
-
-
-
-
-
- If you are running with transactions and logging, the db_printlog
-utility can be a useful debugging aid. The db_printlog utility
-will display the contents of your log files in a human readable (and
-machine-processable) format.
- The db_printlog utility will attempt to display any and all
-logfiles present in a designated db_home directory. For each log record,
-db_printlog will display a line of the form:
- The opening numbers in square brackets are the log sequence number (LSN)
-of the log record being displayed. The first number indicates the log
-file in which the record appears, and the second number indicates the
-offset in that file of the record.
- The first character string identifies the particular log operation being
-reported. The log records corresponding to particular operations are
-described below. The rest of the line consists of name/value pairs.
- The rec field indicates the record type (this is used to dispatch records
-in the log to appropriate recovery functions).
- The txnid field identifies the transaction for which this record was
-written. A txnid of 0 means that the record was written outside the
-context of any transaction. You will see these most frequently for
-checkpoints.
- Finally, the prevlsn contains the LSN of the last record for this
-transaction. By following prevlsn fields, you can accumulate all the
-updates for a particular transaction. During normal abort processing,
-this field is used to quickly access all the records for a particular
-transaction.
- After the initial line identifying the record type, each field of the log
-record is displayed, one item per line. There are several fields that
-appear in many different records and a few fields that appear only in
-some records.
- The list below presents each log record type currently produced with a brief
-description of the operation they describe.
-
- When debugging applications, it is sometimes useful to log, not only the
-actual operations that modify pages, but also the underlying Berkeley DB
-functions being executed. This form of logging can add significant bulk
-to your log, but can permit debugging application errors that are almost
-impossible to find any other way. To turn on these log messages, specify
-the --enable-debug_rop and --enable-debug_wop configuration options when
-configuring Berkeley DB. See Configuring
-Berkeley DB for more information.
- Sometimes it is useful to use the human-readable log output to determine
-which transactions committed and aborted. The awk script, commit.awk,
-found in the db_printlog directory of the Berkeley DB distribution allows you
-to do just that. The command:
- If you need a complete list of both committed and aborted transactions,
-then the script status.awk will produce that. The syntax is:
- Another useful debugging aid is to print out the complete history of a
-transaction. The awk script txn.awk, allows you to do that. The
-command line:
- The awk script fileid.awk, allows you to extract all log records that
-affect particular files. The syntax for the fileid.awk script is:
- where log_output is the output of db_printlog and fids is a
-comma-separated list of fileids. The script will output all log
-records that reference the designated file.
- The awk script pgno.awk, allows you to extract all log records that
-affect particular pages. As currently designed, however, it will
-extract records of all files with the designated page number, so this
-script is most useful in conjunction with the fileid script. The syntax
-for the pgno.awk script is:
- where log_output is the output of db_printlog and pgnolist is a
-comma-separated list of page numbers. The script will output all log
-records that reference the designated page numbers.
- The awk script count.awk will print out the number of log records
-encountered that belonged to some transaction (that is the number of log
-records excluding those for checkpoints and non-transaction protected
-operations).
- The script range.awk will extract a subset of a log. This is useful
-when the output of db_printlog is too large to be reasonably
-manipulated with an editor or other tool.
- The syntax for range.awk is:
- where the sf and so represent the log sequence number
-(LSN) of the beginning of the sublog you wish to extract and ef
-and eo represent the LSN of the end of the sublog you wish to
-extract.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/debug/runtime.html b/bdb/docs/ref/debug/runtime.html
deleted file mode 100644
index 40fec7e82dd..00000000000
--- a/bdb/docs/ref/debug/runtime.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
-
- Normally, when an error occurs in the Berkeley DB library, an integer value
-(either a Berkeley DB specific value, or a system errno value) is
-returned by the function. In some cases, however, this value may be
-insufficient to completely describe the cause of the error, especially
-during initial application debugging.
- There are four interfaces intended to provide applications with
-additional run-time error information. They are
-DBENV->set_errcall, DBENV->set_errfile,
-DBENV->set_errpfx and DBENV->set_verbose.
- If the environment is configured with these interfaces, many Berkeley DB errors
-will result in additional information being written to a file or passed
-as an argument to an application function.
- The Berkeley DB error reporting facilities do not slow performance or
-significantly increase application size, and may be run during normal
-operation as well as during debugging. Where possible, we recommend that
-these options always be configured and the output saved in the filesystem.
-We have found that that this often saves time when debugging installation
-or other system integration problems.
- In addition, there are three routines to assist applications in
-displaying their own error messages: db_strerror,
-DBENV->err and DBENV->errx. The first is a superset of
-the ANSI C strerror interface, and returns a descriptive string for
-any error return from the Berkeley DB library. The DBENV->err and
-DBENV->errx functions use the error message configuration options
-described above to format and display error messages to appropriate
-output devices.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/distrib/layout.html b/bdb/docs/ref/distrib/layout.html
deleted file mode 100644
index b851f62a04c..00000000000
--- a/bdb/docs/ref/distrib/layout.html
+++ /dev/null
@@ -1,74 +0,0 @@
-
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/dumpload/format.html b/bdb/docs/ref/dumpload/format.html
deleted file mode 100644
index fd52e530a02..00000000000
--- a/bdb/docs/ref/dumpload/format.html
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
-
-
-
- There are two output formats used by db_dump and db_dump185.
- In both output formats, the first few lines of the output contain header
-information describing the underlying access method, filesystem page size
-and other bookkeeping information.
- The header information starts with a single line VERSION=N, where N is
-the version number of the dump output format.
- The header information is then output in name=value pairs, where name may
-be any of the keywords listed in the db_load manual page, and
-value will be its value. While this header information can be manually
-edited before the database is reloaded, there is rarely any reason to do
-so, as all of this information can also be specified or overridden by
-command-line arguments to db_load.
- The header information ends with single line HEADER=END.
- Following the header information are the key/data pairs from the database.
-If the database being dumped is of type Btree or Hash, or if the
--k option as been specified, the output will be paired lines of
-text, where the first line of the pair is the key item, and the second
-line of the pair is its corresponding data item. If the database being
-dumped is of type Queue or Recno and the -k has not been
-specified, the output will be lines of text, where each line is the next
-data item for the database. Each of these lines will be preceded by a
-single space.
- If the -p option to db_dump or db_dump185 was
-specified, the key/data lines will consist of single characters
-representing any characters from the database that are printing
-characters and backslash (\) escaped characters
-for any that were not. Backslash characters appearing in the output mean
-one of two things: if the backslash character precedes another backslash
-character, it means that a literal backslash character occurred in the
-key or data item. If the backslash character precedes any other
-character, the next two characters must be interpreted as hexadecimal
-specification of a single character, e.g., \0a is
-a newline character in the ASCII character set.
- Although some care should be exercised, it is perfectly reasonable to use
-standard text editors and tools to edit databases dumped using the
--p option before re-loading them using the db_load
-utility.
- Note that the definition of a printing character may vary from system to
-system, and so database representations created using the -p
-option may be less portable than those created without it.
- If the -p option to db_dump or db_dump185 is
-not specified, each output line will consist of paired hexadecimal values,
-e.g., the line 726f6f74 is the string root in the ASCII
-character set.
- In all output formats, the key and data items are ended by a single line
-DATA=END.
- Where multiple databases have been dumped from a file, the overall output
-will repeat, i.e., a new set of headers and a new set of data items.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/dumpload/text.html b/bdb/docs/ref/dumpload/text.html
deleted file mode 100644
index 569980a1957..00000000000
--- a/bdb/docs/ref/dumpload/text.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-
-
-
- The db_load utility can be used to load text into databases.
-The -T option permits non-database applications to create
-flat-text files that are then loaded into databases for fast,
-highly-concurrent access. For example, the following command loads the
-standard UNIX /etc/passwd file into a database, with the login
-name as the key item and the entire password entry as the data item:
- Note that backslash characters naturally occurring in the text are escaped
-to avoid interpretation as escape characters by db_load.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/dumpload/utility.html b/bdb/docs/ref/dumpload/utility.html
deleted file mode 100644
index f9cb51c11a9..00000000000
--- a/bdb/docs/ref/dumpload/utility.html
+++ /dev/null
@@ -1,45 +0,0 @@
-
-
-
-
-
- There are three utilities used for dumping and loading Berkeley DB
-databases: db_dump, db_dump185 and db_load.
- The db_dump and db_dump185 utilities dump Berkeley DB
-databases into a flat-text representation of the data that can
-be read by db_load. The only difference between them
-is that db_dump reads Berkeley DB version 2 and greater
-database formats, while db_dump185 reads Berkeley DB version
-1.85 and 1.86 database formats.
- The db_load utility reads either the output format used
-by the dump utilities or, optionally, a flat-text representation
-created using other tools, and stores it into a Berkeley DB database.
- Dumping and reloading Hash databases that use user-defined hash functions
-will result in new databases that use the default hash function. While
-using the default hash function may not be optimal for the new database,
-it will continue to work correctly.
- Dumping and reloading Btree databases that use user-defined prefix or
-comparison functions will result in new databases that use the default
-prefix and comparison functions. In which case it is quite likely that
-applications will be unable to retrieve records, and possible that the
-load process itself will fail.
- The only available workaround for either Hash or Btree databases is to
-modify the sources for the db_load utility to load the database
-using the correct hash, prefix and comparison functions.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/create.html b/bdb/docs/ref/env/create.html
deleted file mode 100644
index 374c7a6e005..00000000000
--- a/bdb/docs/ref/env/create.html
+++ /dev/null
@@ -1,73 +0,0 @@
-
-
-
-
-
- The DBENV->open function is the standard function for creating or
-joining a database environment. Transaction-protected or multi-process
-applications should call DBENV->open before making any other calls
-to the Berkeley DB library. Applications must obtain an environment handle from
-the db_env_create function before calling DBENV->open.
-There are a large number of options that you can set to customize
-DBENV->open for your environment. These options fall into four
-broad categories:
- Most applications either specify only the DB_INIT_MPOOL flag or
-they specify all four subsystem initialization flags
-(DB_INIT_MPOOL, DB_INIT_LOCK, DB_INIT_LOG and
-DB_INIT_TXN). The former configuration is for applications that
-simply want to use the basic Access Method interfaces with a shared
-underlying buffer pool, but don't care about recoverability after
-application or system failure. The latter is for applications that need
-recoverability. There are situations where other combinations of the
-initialization flags make sense, but they are rare.
- The DB_RECOVER flag is specified by applications that want to
-perform any necessary database recovery when they start running, i.e., if
-there was a system or application failure the last time they ran, they
-want the databases to be made consistent before they start running again.
-It is not an error to specify this flag when no recovery needs to be
-done.
- The DB_RECOVER_FATAL flag is more special-purpose. It performs
-catastrophic database recovery, and normally requires that some initial
-arrangements be made, i.e., archived log files be brought back into the
-filesystem. Applications should not normally specify this flag. Instead,
-under these rare conditions, the db_recover utility should be
-used.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/error.html b/bdb/docs/ref/env/error.html
deleted file mode 100644
index 1a79d8fe550..00000000000
--- a/bdb/docs/ref/env/error.html
+++ /dev/null
@@ -1,57 +0,0 @@
-
-
-
-
-
- Berkeley DB offers programmatic support for displaying error return values.
-The db_strerror interface returns a pointer to the error
-message corresponding to any Berkeley DB error return, similar to the ANSI C
-strerror interface, but able to handle both system error returns and
-Berkeley DB specific return values.
- For example:
- There are also two additional error functions, DBENV->err and
-DBENV->errx. These functions work like the ANSI C printf
-interface, taking a printf-style format string and argument list, and
-writing a message constructed from the format string and arguments.
- The DBENV->err function appends the standard error string to the
-constructed message and the DBENV->errx function does not.
- Error messages can be configured always to include a prefix (e.g., the
-program name) using the DBENV->set_errpfx interface.
- These functions provide simpler ways of displaying Berkeley DB error messages:
- For example, if the program was called "my_app", attempting to open an
-environment home directory in "/tmp/home", and the open call returned a
-permission error, the error messages shown would look like:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/intro.html b/bdb/docs/ref/env/intro.html
deleted file mode 100644
index a555c2f0f9e..00000000000
--- a/bdb/docs/ref/env/intro.html
+++ /dev/null
@@ -1,56 +0,0 @@
-
-
-
-
-
- A Berkeley DB environment is an encapsulation of one or more databases, log
-files and shared information about the database environment such as shared
-memory buffer cache pages.
- The simplest way to administer a Berkeley DB application environment is to
-create a single home directory that stores the files for the
-applications that will share the environment. The environment home
-directory must be created before any Berkeley DB applications are run. Berkeley DB
-itself never creates the environment home directory. The environment can
-then be identified by the name of that directory.
- An environment may be shared by any number of applications as well as by
-any number of threads within the applications. It is possible for an
-environment to include resources from other directories on the system,
-and applications often choose to distribute resources to other directories
-or disks for performance or other reasons. However, by default, the
-databases, shared regions (the locking, logging, memory pool, and
-transaction shared memory areas) and log files will be stored in a single
-directory hierarchy.
- It is important to realize that all applications sharing a database
-environment implicitly trust each other. They have access to each other's
-data as it resides in the shared regions and they will share resources
-such as buffer space and locks. At the same time, any applications using
-the same databases must share an environment if consistency is
-to be maintained between them.
- The Berkeley DB environment is created and described by the db_env_create
-and DBENV->open interfaces. In situations where customization is
-desired, such as storing log files on a separate disk drive, applications
-must describe the customization by either creating an environment
-configuration file in the environment home directory or by arguments
-passed to the DBENV->open interface. See the documentation on that
-function for details on this procedure.
- Once an environment has been created, database files specified using
-relative pathnames will be named relative to the home directory. Using
-pathnames relative to the home directory allows the entire environment
-to be easily moved to facilitate restoring and recovering a database in
-a different directory or on a different system.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/naming.html b/bdb/docs/ref/env/naming.html
deleted file mode 100644
index fd575396210..00000000000
--- a/bdb/docs/ref/env/naming.html
+++ /dev/null
@@ -1,145 +0,0 @@
-
-
-
-
-
- The most important task of the environment is to structure file naming
-within Berkeley DB.
- Each of the locking, logging, memory pool and transaction subsystems of
-Berkeley DB require shared memory regions, backed by the filesystem. Further,
-cooperating applications (or multiple invocations of the same application)
-must agree on the location of the shared memory regions and other files
-used by the Berkeley DB subsystems, the log files used by the logging subsystem,
-and, of course, the data files. Although it is possible to specify full
-pathnames to all Berkeley DB functions, this is cumbersome and requires
-that applications be recompiled when database files are moved.
- Applications are normally expected to specify a single directory home for
-their database. This can be done easily in the call to DBENV->open
-by specifying a value for the db_home argument. There are more
-complex configurations where it may be desirable to override
-db_home or provide supplementary path information.
- The following describes the possible ways in which file naming information
-may be specified to the Berkeley DB library. The specific circumstances and
-order in which these ways are applied are described in a subsequent
-paragraph.
- The DB_HOME environment variable is intended to permit users and system
-administrators to override application and installation defaults, e.g.:
- Application writers are encouraged to support the -h option
-found in the supporting Berkeley DB utilities to let users specify a database
-home.
- The characters delimiting the two parts of the entry may be one or more
-whitespace characters, and trailing whitespace characters are discarded.
-All empty lines or lines whose first character is a whitespace or hash
-(#) character will be ignored. Each line must specify both
-the NAME and the VALUE of the pair. The specific NAME VALUE pairs are
-documented in the manual DBENV->set_data_dir,
-DBENV->set_lg_dir and DBENV->set_tmp_dir pages.
- The DB_CONFIG configuration file is intended to permit systems to
-customize file location for an environment independent of applications
-using that database. For example, a database administrator can move the
-database log and data files to a different location without application
-recompilation.
- The following describes the specific circumstances and order in which the
-different ways of specifying file naming information are applied. Berkeley DB
-file name processing proceeds sequentially through the following steps:
- On UNIX systems, an absolute pathname is defined as any pathname that
-begins with a leading slash (/).
- On Windows systems, an absolute pathname is any pathname that begins with
-a leading slash or leading backslash (\), or any
-pathname beginning with a single alphabetic character, a colon and a
-leading slash or backslash, e.g., C:/tmp.
- The common model for a Berkeley DB environment is one where only the DB_HOME
-environment variable, or the db_home argument, is specified. In
-this case, all data file names are relative to that directory, and all
-files created by the Berkeley DB subsystems will be created in that directory.
- The more complex model for a transaction environment might be one where
-a database home is specified, using either the DB_HOME environment
-variable or the db_home argument to DBENV->open, and then
-the data directory and logging directory are set to the relative path
-names of directories underneath the environment home.
- Store data files in /a/database/data1 and /b/data2, and
-all other files in the directory /a/database. Any data files
-that are created will be created in /b/data2, because it is the
-first DB_DATA_DIR directory specified:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/open.html b/bdb/docs/ref/env/open.html
deleted file mode 100644
index f13675c7365..00000000000
--- a/bdb/docs/ref/env/open.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- Once the environment has been created, database handles may be created
-and then opened within the environment. This is done by calling the
-db_create interface and specifying the appropriate environment
-as an argument.
- File naming, database operations and error handling will all be done as
-specified for the environment, e.g., if the DB_INIT_LOCK or
-DB_INIT_CDB flags were specified when the environment was created
-or joined, database operations will automatically perform all necessary
-locking operations for the application.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/region.html b/bdb/docs/ref/env/region.html
deleted file mode 100644
index 0dfa19672e5..00000000000
--- a/bdb/docs/ref/env/region.html
+++ /dev/null
@@ -1,66 +0,0 @@
-
-
-
-
-
- Each of the Berkeley DB subsystems within an environment is described by one or
-more regions. The regions contain all of the per-process and per-thread
-shared information, including mutexes, that comprise a Berkeley DB environment.
-These regions are created in one of three areas, depending on the flags
-specified to the DBENV->open function:
- The system memory used by Berkeley DB is potentially useful past the lifetime
-of any particular process. Therefore, additional cleanup may be necessary
-after an application fails, as there may be no way for Berkeley DB to ensure
-that system resources backing the shared memory regions are returned to
-the system.
- The system memory that is used is architecture-dependent. For example,
-on systems supporting X/Open-style shared memory interfaces, e.g., UNIX
-systems, the shmget(2) and related System V IPC interfaces are
-used. Additionally, VxWorks systems use system memory.
-In these cases, an initial segment ID must be specified by the
-application to ensure that applications do not overwrite each other's
-database environments, and so that the number of segments created does
-not grow without bound. See the DBENV->set_shm_key function for more
-information.
- Any files created in the filesystem to back the regions are created in
-the environment home directory specified to the DBENV->open call.
-These files are named __db.###, e.g., __db.001, __db.002 and so on.
-When region files are backed by the filesystem, one file per region is
-created. When region files are backed by system memory, a single file
-will still be created, as there must be a well-known name in the
-filesystem so that multiple processes can locate the system shared memory
-that is being used by the environment.
- Statistics about the shared memory regions in the environment can be
-displayed using the -e option to the db_stat utility.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/remote.html b/bdb/docs/ref/env/remote.html
deleted file mode 100644
index 3cd44a539bc..00000000000
--- a/bdb/docs/ref/env/remote.html
+++ /dev/null
@@ -1,48 +0,0 @@
-
-
-
-
-
- When regions are backed by the filesystem, it is a common error to attempt
-to create Berkeley DB environments backed by remote file systems such as the
-Network File System (NFS) or the Andrew File System (AFS). Remote
-filesystems rarely support mapping files into process memory, and even
-more rarely support correct semantics for mutexes after the attempt
-succeeds. For this reason, we strongly recommend that the database
-environment directory reside in a local filesystem.
- For remote file systems that do allow system files to be mapped into
-process memory, home directories accessed via remote file systems cannot
-be used simultaneously from multiple clients. None of the commercial
-remote file systems available today implement coherent, distributed shared
-memory for remote-mounted files. As a result, different machines will
-see different versions of these shared regions and the system behavior is
-undefined.
- Databases, log files and temporary files may be placed on remote
-filesystems, as long as the remote filesystem fully supports
-standard POSIX filesystem semantics, although the application may incur
-a performance penalty for doing so. Obviously, NFS-mounted databases
-cannot be accessed from more than one Berkeley DB environment (and therefore
-from more than one system), at a time since no Berkeley DB database may be
-accessed from more than one Berkeley DB environment at a time.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/env/security.html b/bdb/docs/ref/env/security.html
deleted file mode 100644
index 84dab59b260..00000000000
--- a/bdb/docs/ref/env/security.html
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-
-
-
- The following are security issues that should be considered when writing
-Berkeley DB applications:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/install/file.html b/bdb/docs/ref/install/file.html
deleted file mode 100644
index 2ecb240e242..00000000000
--- a/bdb/docs/ref/install/file.html
+++ /dev/null
@@ -1,37 +0,0 @@
-
-
-
-
-
- The file(1) utility is a UNIX utility that examines and
-classifies files, based on information found in its database of file
-types, the /etc/magic file. The following information may be added
-to your system's /etc/magic file to enable file(1) to
-correctly identify Berkeley DB database files.
- The file(1) utility magic(5) information for the
-standard System V UNIX implementation of the file(1) utility
-is included in the Berkeley DB distribution for both
-big-endian (e.g., Sparc) and
-little-endian (e.g., x86) architectures.
- The file(1) utility magic(5) information for
-Release 3.X of Ian Darwin's implementation of the file utility (as
-distributed by FreeBSD and most Linux distributions) is included in the
-Berkeley DB distribution. This magic.txt information
-is correct for both big-endian and little-endian architectures.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/install/magic.s5.be.txt b/bdb/docs/ref/install/magic.s5.be.txt
deleted file mode 100644
index 1b8fcc1089e..00000000000
--- a/bdb/docs/ref/install/magic.s5.be.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-# Berkeley DB
-# $Id: magic.s5.be.txt,v 10.4 2000/07/07 21:02:22 krinsky Exp $
-#
-# System V /etc/magic files: big-endian version.
-#
-# Hash 1.85/1.86 databases store metadata in network byte order.
-# Btree 1.85/1.86 databases store the metadata in host byte order.
-# Hash and Btree 2.X and later databases store the metadata in host byte order.
-
-0 long 0x00053162 Berkeley DB 1.85/1.86 (Btree,
->4 long 0x00000002 version 2,
->4 long 0x00000003 version 3,
->0 long 0x00053162 native byte-order)
-
-0 long 0x62310500 Berkeley DB 1.85/1.86 (Btree,
->4 long 0x02000000 version 2,
->4 long 0x03000000 version 3,
->0 long 0x62310500 little-endian)
-
-12 long 0x00053162 Berkeley DB (Btree,
->16 long 0x00000004 version 4,
->16 long 0x00000005 version 5,
->16 long 0x00000006 version 6,
->16 long 0x00000007 version 7,
->16 long 0x00000008 version 8,
->16 long 0x00000009 version 9,
->12 long 0x00053162 native byte-order)
-
-12 long 0x62310500 Berkeley DB (Btree,
->16 long 0x04000000 version 4,
->16 long 0x05000000 version 5,
->16 long 0x06000000 version 6,
->16 long 0x07000000 version 7,
->16 long 0x08000000 version 8,
->16 long 0x09000000 version 9,
->12 long 0x62310500 little-endian)
-
-0 long 0x00061561 Berkeley DB
->4 long >2 1.86
->4 long <3 1.85
->0 long 0x00061561 (Hash,
->4 long 2 version 2,
->4 long 3 version 3,
->8 long 0x000004D2 little-endian)
->8 long 0x000010E1 native byte-order)
-
-12 long 0x00061561 Berkeley DB (Hash,
->16 long 0x00000004 version 4,
->16 long 0x00000005 version 5,
->16 long 0x00000006 version 6,
->16 long 0x00000007 version 7,
->16 long 0x00000008 version 8,
->16 long 0x00000009 version 9,
->12 long 0x00061561 native byte-order)
-
-12 long 0x61150600 Berkeley DB (Hash,
->16 long 0x04000000 version 4,
->16 long 0x05000000 version 5,
->16 long 0x06000000 version 6,
->16 long 0x07000000 version 7,
->16 long 0x08000000 version 8,
->16 long 0x09000000 version 9,
->12 long 0x61150600 little-endian)
-
-12 long 0x00042253 Berkeley DB (Queue,
->16 long 0x00000001 version 1,
->16 long 0x00000002 version 2,
->16 long 0x00000003 version 3,
->16 long 0x00000004 version 4,
->16 long 0x00000005 version 5,
->16 long 0x00000006 version 6,
->16 long 0x00000007 version 7,
->16 long 0x00000008 version 8,
->16 long 0x00000009 version 9,
->12 long 0x00042253 native byte-order)
-
-12 long 0x53220400 Berkeley DB (Queue,
->16 long 0x01000000 version 1,
->16 long 0x02000000 version 2,
->16 long 0x03000000 version 3,
->16 long 0x04000000 version 4,
->16 long 0x05000000 version 5,
->16 long 0x06000000 version 6,
->16 long 0x07000000 version 7,
->16 long 0x08000000 version 8,
->16 long 0x09000000 version 9,
->12 long 0x53220400 little-endian)
diff --git a/bdb/docs/ref/install/magic.s5.le.txt b/bdb/docs/ref/install/magic.s5.le.txt
deleted file mode 100644
index c8871fedf9a..00000000000
--- a/bdb/docs/ref/install/magic.s5.le.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-# Berkeley DB
-# $Id: magic.s5.le.txt,v 10.4 2000/07/07 21:02:22 krinsky Exp $
-#
-# System V /etc/magic files: little-endian version.
-#
-# Hash 1.85/1.86 databases store metadata in network byte order.
-# Btree 1.85/1.86 databases store the metadata in host byte order.
-# Hash and Btree 2.X and later databases store the metadata in host byte order.
-
-0 long 0x00053162 Berkeley DB 1.85/1.86 (Btree,
->4 long 0x00000002 version 2,
->4 long 0x00000003 version 3,
->0 long 0x00053162 native byte-order)
-
-0 long 0x62310500 Berkeley DB 1.85/1.86 (Btree,
->4 long 0x02000000 version 2,
->4 long 0x03000000 version 3,
->0 long 0x62310500 big-endian)
-
-12 long 0x00053162 Berkeley DB (Btree,
->16 long 0x00000004 version 4,
->16 long 0x00000005 version 5,
->16 long 0x00000006 version 6,
->16 long 0x00000007 version 7,
->16 long 0x00000008 version 8,
->16 long 0x00000009 version 9,
->12 long 0x00053162 native byte-order)
-
-12 long 0x62310500 Berkeley DB (Btree,
->16 long 0x04000000 version 4,
->16 long 0x05000000 version 5,
->16 long 0x06000000 version 6,
->16 long 0x07000000 version 7,
->16 long 0x08000000 version 8,
->16 long 0x09000000 version 9,
->12 long 0x62310500 big-endian)
-
-0 long 0x61150600 Berkeley DB
->4 long >0x02000000 1.86
->4 long <0x03000000 1.85
->0 long 0x00061561 (Hash,
->4 long 0x02000000 version 2,
->4 long 0x03000000 version 3,
->8 long 0xD2040000 native byte-order)
->8 long 0xE1100000 big-endian)
-
-12 long 0x00061561 Berkeley DB (Hash,
->16 long 0x00000004 version 4,
->16 long 0x00000005 version 5,
->16 long 0x00000006 version 6,
->16 long 0x00000007 version 7,
->16 long 0x00000008 version 8,
->16 long 0x00000009 version 9,
->12 long 0x00061561 native byte-order)
-
-12 long 0x61150600 Berkeley DB (Hash,
->16 long 0x04000000 version 4,
->16 long 0x05000000 version 5,
->16 long 0x06000000 version 6,
->16 long 0x07000000 version 7,
->16 long 0x08000000 version 8,
->16 long 0x09000000 version 9,
->12 long 0x61150600 big-endian)
-
-12 long 0x00042253 Berkeley DB (Queue,
->16 long 0x00000001 version 1,
->16 long 0x00000002 version 2,
->16 long 0x00000003 version 3,
->16 long 0x00000004 version 4,
->16 long 0x00000005 version 5,
->16 long 0x00000006 version 6,
->16 long 0x00000007 version 7,
->16 long 0x00000008 version 8,
->16 long 0x00000009 version 9,
->12 long 0x00042253 native byte-order)
-
-12 long 0x53220400 Berkeley DB (Queue,
->16 long 0x01000000 version 1,
->16 long 0x02000000 version 2,
->16 long 0x03000000 version 3,
->16 long 0x04000000 version 4,
->16 long 0x05000000 version 5,
->16 long 0x06000000 version 6,
->16 long 0x07000000 version 7,
->16 long 0x08000000 version 8,
->16 long 0x09000000 version 9,
->12 long 0x53220400 big-endian)
diff --git a/bdb/docs/ref/install/magic.txt b/bdb/docs/ref/install/magic.txt
deleted file mode 100644
index c28329f4078..00000000000
--- a/bdb/docs/ref/install/magic.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-# Berkeley DB
-# $Id: magic.txt,v 10.10 2000/07/07 21:02:22 krinsky Exp $
-#
-# Ian Darwin's file /etc/magic files: big/little-endian version.
-#
-# Hash 1.85/1.86 databases store metadata in network byte order.
-# Btree 1.85/1.86 databases store the metadata in host byte order.
-# Hash and Btree 2.X and later databases store the metadata in host byte order.
-
-0 long 0x00061561 Berkeley DB
->8 belong 4321
->>4 belong >2 1.86
->>4 belong <3 1.85
->>4 belong >0 (Hash, version %d, native byte-order)
->8 belong 1234
->>4 belong >2 1.86
->>4 belong <3 1.85
->>4 belong >0 (Hash, version %d, little-endian)
-
-0 belong 0x00061561 Berkeley DB
->8 belong 4321
->>4 belong >2 1.86
->>4 belong <3 1.85
->>4 belong >0 (Hash, version %d, big-endian)
->8 belong 1234
->>4 belong >2 1.86
->>4 belong <3 1.85
->>4 belong >0 (Hash, version %d, native byte-order)
-
-0 long 0x00053162 Berkeley DB 1.85/1.86
->4 long >0 (Btree, version %d, native byte-order)
-0 belong 0x00053162 Berkeley DB 1.85/1.86
->4 belong >0 (Btree, version %d, big-endian)
-0 lelong 0x00053162 Berkeley DB 1.85/1.86
->4 lelong >0 (Btree, version %d, little-endian)
-
-12 long 0x00061561 Berkeley DB
->16 long >0 (Hash, version %d, native byte-order)
-12 belong 0x00061561 Berkeley DB
->16 belong >0 (Hash, version %d, big-endian)
-12 lelong 0x00061561 Berkeley DB
->16 lelong >0 (Hash, version %d, little-endian)
-
-12 long 0x00053162 Berkeley DB
->16 long >0 (Btree, version %d, native byte-order)
-12 belong 0x00053162 Berkeley DB
->16 belong >0 (Btree, version %d, big-endian)
-12 lelong 0x00053162 Berkeley DB
->16 lelong >0 (Btree, version %d, little-endian)
-
-12 long 0x00042253 Berkeley DB
->16 long >0 (Queue, version %d, native byte-order)
-12 belong 0x00042253 Berkeley DB
->16 belong >0 (Queue, version %d, big-endian)
-12 lelong 0x00042253 Berkeley DB
->16 lelong >0 (Queue, version %d, little-endian)
diff --git a/bdb/docs/ref/intro/data.html b/bdb/docs/ref/intro/data.html
deleted file mode 100644
index e9d6ead064d..00000000000
--- a/bdb/docs/ref/intro/data.html
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-
-
-
- Cheap, powerful computing and networking have created countless new
-applications that could not have existed a decade ago. The advent of
-the World-Wide Web, and its influence in driving the Internet into homes
-and businesses, is one obvious example. Equally important, though, is
-the from large, general-purpose desktop and server computers
-toward smaller, special-purpose devices with built-in processing and
-communications services.
- As computer hardware has spread into virtually every corner of our
-lives, of course, software has followed. Software developers today are
-building applications not just for conventional desktop and server
-environments, but also for handheld computers, home appliances,
-networking hardware, cars and trucks, factory floor automation systems,
-and more.
- While these operating environments are diverse, the problems that
-software engineers must solve in them are often strikingly similar. Most
-systems must deal with the outside world, whether that means
-communicating with users or controlling machinery. As a result, most
-need some sort of I/O system. Even a simple, single-function system
-generally needs to handle multiple tasks, and so needs some kind of
-operating system to schedule and manage control threads. Also, many
-computer systems must store and retrieve data to track history, record
-configuration settings, or manage access.
- Data management can be very simple. In some cases, just recording
-configuration in a flat text file is enough. More often, though,
-programs need to store and search a large amount of data, or
-structurally complex data. Database management systems are tools that
-programmers can use to do this work quickly and efficiently using
-off-the-shelf software.
- Of course, database management systems have been around for a long time.
-Data storage is a problem dating back to the earliest days of computing.
-Software developers can choose from hundreds of good,
-commercially-available database systems. The problem is selecting the
-one that best solves the problems that their applications face.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/dbis.html b/bdb/docs/ref/intro/dbis.html
deleted file mode 100644
index 10c4abd9585..00000000000
--- a/bdb/docs/ref/intro/dbis.html
+++ /dev/null
@@ -1,159 +0,0 @@
-
-
-
-
-
- So far, we've discussed database systems in general terms. It's time
-now to consider Berkeley DB in particular and see how it fits into the
-framework we have introduced. The key question is, what kinds of
-applications should use Berkeley DB?
- Berkeley DB is an open source embedded database library that provides
-scalable, high-performance, transaction-protected data management
-services to applications. Berkeley DB provides a simple function-call API
-for data access and management.
- By "open source," we mean that Berkeley DB is distributed under a license that
-conforms to the Open
-Source Definition. This license guarantees that Berkeley DB is freely
-available for use and redistribution in other open source products.
-Sleepycat Software sells
-commercial licenses for redistribution in proprietary applications, but
-in all cases the complete source code for Berkeley DB is freely available for
-download and use.
- Berkeley DB is embedded because it links directly into the application. It
-runs in the same address space as the application. As a result, no
-inter-process communication, either over the network or between
-processes on the same machine, is required for database operations.
-Berkeley DB provides a simple function-call API for a number of programming
-languages, including C, C++, Java, Perl, Tcl, Python, and PHP. All
-database operations happen inside the library. Multiple processes, or
-multiple threads in a single process, can all use the database at the
-same time as each uses the Berkeley DB library. Low-level services like
-locking, transaction logging, shared buffer management, memory
-management, and so on are all handled transparently by the library.
- The library is extremely portable. It runs under almost all UNIX and
-Linux variants, Windows, and a number of embedded real-time operating
-systems. It runs on both 32-bit and 64-bit systems.
-It has been deployed on high-end
-Internet servers, desktop machines, and on palmtop computers, set-top
-boxes, in network switches, and elsewhere. Once Berkeley DB is linked into
-the application, the end user generally does not know that there's a
-database present at all.
- Berkeley DB is scalable in a number of respects. The database library itself
-is quite compact (under 300 kilobytes of text space on common
-architectures), but it can manage databases up to 256 terabytes in size.
-It also supports high concurrency, with thousands of users operating on
-the same database at the same time. Berkeley DB is small enough to run in
-tightly constrained embedded systems, but can take advantage of
-gigabytes of memory and terabytes of disk on high-end server machines.
- Berkeley DB generally outperforms relational and object-oriented database
-systems in embedded applications for a couple of reasons. First, because
-the library runs in the same address space, no inter-process
-communication is required for database operations. The cost of
-communicating between processes on a single machine, or among machines
-on a network, is much higher than the cost of making a function call.
-Second, because Berkeley DB uses a simple function-call interface for all
-operations, there is no query language to parse, and no execution plan
-to produce.
- Berkeley DB applications can choose the storage structure that best suits the
-application. Berkeley DB supports hash tables, B-trees, simple
-record-number-based storage, and persistent queues. Programmers can
-create tables using any of these storage structures, and can mix
-operations on different kinds of tables in a single application.
- Hash tables are generally good for very large databases that need
-predictable search and update times for random-access records. Hash
-tables allow users to ask, "Does this key exist?" or to fetch a record
-with a known key. Hash tables do not allow users to ask for records
-with keys that are close to a known key.
- B-trees are better for range-based searches, as when the application
-needs to find all records with keys between some starting and ending
-value. B-trees also do a better job of exploiting locality
-of reference. If the application is likely to touch keys near each
-other at the same time, the B-trees work well. The tree structure keeps
-keys that are close together near one another in storage, so fetching
-nearby values usually doesn't require a disk access.
- Record-number-based storage is natural for applications that need
-to store and fetch records, but that do not have a simple way to
-generate keys of their own. In a record number table, the record
-number is the key for the record. Berkeley DB will can generate these
-record numbers automatically.
- Queues are well-suited for applications that create records, and then
-must deal with those records in creation order. A good example is
-on-line purchasing systems. Orders can enter the system at any time,
-but should generally be filled in the order in which they were placed.
- Berkeley DB offers important data management services, including concurrency,
-transactions, and recovery. All of these services work on all of the
-storage structures.
- Many users can work on the same database concurrently. Berkeley DB handles
-locking transparently, ensuring that two users working on the same
-record do not interfere with one another.
- The library provides strict ACID transaction semantics. Some systems
-allow the user to relax, for example, the isolation guarantees that the
-database system makes. Berkeley DB ensures that all applications can see only
-committed updates.
- Multiple operations can be grouped into a single transaction, and can
-be committed or rolled back atomically. Berkeley DB uses a technique called
-two-phase locking to be sure that concurrent transactions
-are isolated from one another, and a technique called
-write-ahead logging to guarantee that committed changes
-survive application, system, or hardware failures.
- When an application starts up, it can ask Berkeley DB to run recovery.
-Recovery restores the database to a clean state, with all committed
-changes present, even after a crash. The database is guaranteed to be
-consistent and all committed changes are guaranteed to be present when
-recovery completes.
- An application can specify, when it starts up, which data management
-services it will use. Some applications need fast,
-single-user, non-transactional B-tree data storage. In that case, the
-application can disable the locking and transaction systems, and will
-not incur the overhead of locking or logging. If an application needs
-to support multiple concurrent users, but doesn't need transactions, it
-can turn on locking without transactions. Applications that need
-concurrent, transaction-protected database access can enable all of the
-subsystems.
- In all these cases, the application uses the same function-call API to
-fetch and update records.
- Berkeley DB was designed to provide industrial-strength database services to
-application developers, without requiring them to become database
-experts. It is a classic C-library style toolkit, providing
-a broad base of functionality to application writers. Berkeley DB was designed
-by programmers, for programmers: its modular design surfaces simple,
-orthogonal interfaces to core services, and it provides mechanism (for
-example, good thread support) without imposing policy (for example, the
-use of threads is not required). Just as importantly, Berkeley DB allows
-developers to balance performance against the need for crash recovery
-and concurrent use. An application can use the storage structure that
-provides the fastest access to its data and can request only the degree
-of logging and locking that it needs.
- Because of the tool-based approach and separate interfaces for each
-Berkeley DB subsystem, you can support a complete transaction environment for
-other system operations. Berkeley DB even allows you to wrap transactions
-around the standard UNIX file read and write operations! Further, Berkeley DB
-was designed to interact correctly with the native system's toolset, a
-feature no other database package offers. For example, Berkeley DB supports
-hot backups (database backups while the database is in use), using
-standard UNIX system utilities, e.g., dump, tar, cpio, pax or even cp.
- Finally, because scripting language interfaces are available for Berkeley DB
-(notably Tcl and Perl), application writers can build incredibly powerful
-database engines with little effort. You can build transaction-protected
-database applications using your favorite scripting languages, an
-increasingly important feature in a world using CGI scripts to deliver
-HTML.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/dbisnot.html b/bdb/docs/ref/intro/dbisnot.html
deleted file mode 100644
index a55fa71763e..00000000000
--- a/bdb/docs/ref/intro/dbisnot.html
+++ /dev/null
@@ -1,146 +0,0 @@
-
-
-
-
-
- In contrast to most other database systems, Berkeley DB provides relatively
-simple data access services.
- Records in Berkeley DB are (key, value) pairs. Berkeley DB
-supports only a few logical operations on records. They are:
- Notice that Berkeley DB never operates on the value part of a record.
-Values are simply payload, to be
-stored with keys and reliably delivered back to the application on
-demand.
- Both keys and values can be arbitrary bit strings, either fixed-length
-or variable-length. As a result, programmers can put native programming
-language data structures into the database without converting them to
-a foreign record format first. Storage and retrieval are very simple,
-but the application needs to know what the structure of a key and a
-value is in advance. It cannot ask Berkeley DB, because Berkeley DB doesn't know.
- This is an important feature of Berkeley DB, and one worth considering more
-carefully. On the one hand, Berkeley DB cannot provide the programmer with
-any information on the contents or structure of the values that it
-stores. The application must understand the keys and values that it
-uses. On the other hand, there is literally no limit to the data types
-that can be store in a Berkeley DB database. The application never needs to
-convert its own program data into the data types that Berkeley DB supports.
-Berkeley DB is able to operate on any data type the application uses, no
-matter how complex.
- Because both keys and values can be up to four gigabytes in length, a
-single record can store images, audio streams, or other large data
-values. Large values are not treated specially in Berkeley DB. They are
-simply broken into page-sized chunks, and reassembled on demand when
-the application needs them. Unlike some other database systems, Berkeley DB
-offers no special support for binary large objects (BLOBs).
- Berkeley DB is not a relational database.
- First, Berkeley DB does not support SQL queries. All access to data is through
-the Berkeley DB API. Developers must learn a new set of interfaces in order
-to work with Berkeley DB. Although the interfaces are fairly simple, they are
-non-standard.
- SQL support is a double-edged sword. One big advantage of relational
-databases is that they allow users to write simple declarative queries
-in a high-level language. The database system knows everything about
-the data and can carry out the command. This means that it's simple to
-search for data in new ways, and to ask new questions of the database.
-No programming is required.
- On the other hand, if a programmer can predict in advance how an
-application will access data, then writing a low-level program to get
-and store records can be faster. It eliminates the overhead of query
-parsing, optimization, and execution. The programmer must understand
-the data representation, and must write the code to do the work, but
-once that's done, the application can be very fast.
- Second, Berkeley DB has no notion of schema in the way that
-relational systems do. Schema is the structure of records in tables,
-and the relationships among the tables in the database. For example, in
-a relational system the programmer can create a record from a fixed menu
-of data types. Because the record types are declared to the system, the
-relational engine can reach inside records and examine individual values
-in them. In addition, programmers can use SQL to declare relationships
-among tables, and to create indexes on tables. Relational engines
-usually maintain these relationships and indexes automatically.
- In Berkeley DB, the key and value in a record are opaque
-to Berkeley DB. They may have a rich
-internal structure, but the library is unaware of it. As a result, Berkeley DB
-cannot decompose the value part of a record into its constituent parts,
-and cannot use those parts to find values of interest. Only the
-application, which knows the data structure, can do that.
- Berkeley DB does allow programmers to create indexes on tables, and to use
-those indexes to speed up searches. However, the programmer has no way
-to tell the library how different tables and indexes are related. The
-application needs to make sure that they all stay consistent. In the
-case of indexes in particular, if the application puts a new record into
-a table, it must also put a new record in the index for it. It's
-generally simple to write a single function to make the required
-updates, but it is work that relational systems do automatically.
- Berkeley DB is not a relational system. Relational database systems are
-semantically rich and offer high-level database access. Compared to such
-systems, Berkeley DB is a high-performance, transactional library for record
-storage. It's possible to build a relational system on top of Berkeley DB. In
-fact, the popular MySQL relational system uses Berkeley DB for
-transaction-protected table management, and takes care of all the SQL
-parsing and execution. It uses Berkeley DB for the storage level, and provides
-the semantics and access tools.
- Object-oriented databases are designed for very tight integration with
-object-oriented programming languages. Berkeley DB is written entirely in the
-C programming language. It includes language bindings for C++, Java,
-and other languages, but the library has no information about the
-objects created in any object-oriented application. Berkeley DB never makes
-method calls on any application object. It has no idea what methods are
-defined on user objects, and cannot see the public or private members
-of any instance. The key and value part of all records are opaque to
-Berkeley DB.
- Berkeley DB cannot automatically page in referenced objects, as some
-object-oriented databases do. The object-oriented application programmer
-must decide what records are required, and must fetch them by making
-method calls on Berkeley DB objects.
- Berkeley DB does not support network-style navigation among records, as
-network databases do. Records in a Berkeley DB table may move around over
-time, as new records are added to the table and old ones are deleted.
-Berkeley DB is able to do fast searches for records based on keys, but there
-is no way to create a persistent physical pointer to a record.
-Applications can only refer to records by key, not by address.
- Berkeley DB is not a standalone database server. It is a library, and runs in
-the address space of the application that uses it. If more than one
-application links in Berkeley DB, then all can use the same database at the
-same time; the library handles coordination among the applications, and
-guarantees that they do not interfere with one another.
- Recent releases of Berkeley DB allow programmers to compile the library as a
-standalone process, and to use RPC stubs to connect to it and to carry
-out operations. However, there are some important limitations to this
-feature. The RPC stubs provide exactly the same API that the library
-itself does. There is no higher-level access provided by the standalone
-process. Tuning the standalone process is difficult, since Berkeley DB does
-no threading in the library (applications can be threaded, but the
-library never creates a thread on its own).
- It is possible to build a server application that uses Berkeley DB for data
-management. For example, many commercial and open source Lightweight
-Directory Access Protocol (LDAP) servers use Berkeley DB for record storage.
-LDAP clients connect to these servers over the network. Individual
-servers make calls through the Berkeley DB API to find records and return them
-to clients. On its own, however, Berkeley DB is not a server.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/distrib.html b/bdb/docs/ref/intro/distrib.html
deleted file mode 100644
index a5ff52263c2..00000000000
--- a/bdb/docs/ref/intro/distrib.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- The Berkeley DB distribution includes complete source code for the Berkeley DB
-library, including all three Berkeley DB products and their supporting
-utilities, as well as complete documentation in HTML format.
- The distribution does not include pre-built binaries or libraries, or
-hard-copy documentation. Pre-built libraries and binaries for some
-architecture/compiler combinations are available as part of Sleepycat
-Software's Berkeley DB support services.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/need.html b/bdb/docs/ref/intro/need.html
deleted file mode 100644
index 771dd98908c..00000000000
--- a/bdb/docs/ref/intro/need.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- Berkeley DB is an ideal database system for applications that need fast,
-scalable, and reliable embedded database management. For applications
-that need different services, however, it can be a poor choice.
- First, do you need the ability to access your data in ways you cannot
-predict in advance? If your users want to be able to enter SQL
-queries to perform
-complicated searches that you cannot program into your application to
-begin with, then you should consider a relational engine instead. Berkeley DB
-requires a programmer to write code in order to run a new kind of query.
- On the other hand, if you can predict your data access patterns up front
--- and in particular if you need fairly simple key/value lookups -- then
-Berkeley DB is a good choice. The queries can be coded up once, and will then
-run very quickly because there is no SQL to parse and execute.
- Second, are there political arguments for or against a standalone
-relational server? If you're building an application for your own use
-and have a relational system installed with administrative support
-already, it may be simpler to use that than to build and learn Berkeley DB.
-On the other hand, if you'll be shipping many copies of your application
-to customers, and don't want your customers to have to buy, install,
-and manage a separate database system, then Berkeley DB may be a better
-choice.
- Third, are there any technical advantages to an embedded database? If
-you're building an application that will run unattended for long periods
-of time, or for end users who are not sophisticated administrators, then
-a separate server process may be too big a burden. It will require
-separate installation and management, and if it creates new ways for
-the application to fail, or new complexities to master in the field,
-then Berkeley DB may be a better choice.
- The fundamental question is, how closely do your requirements match the
-Berkeley DB design? Berkeley DB was conceived and built to provide fast, reliable,
-transaction-protected record storage. The library itself was never
-intended to provide interactive query support, graphical reporting
-tools, or similar services that some other database systems provide. We
-have tried always to err on the side of minimalism and simplicity. By
-keeping the library small and simple, we create fewer opportunities for
-bugs to creep in, and we guarantee that the database system stays fast,
-because there is very little code to execute. If your application needs
-that set of features, then Berkeley DB is almost certainly the best choice
-for you.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/products.html b/bdb/docs/ref/intro/products.html
deleted file mode 100644
index ce04135f03a..00000000000
--- a/bdb/docs/ref/intro/products.html
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
-
-
-
- Sleepycat Software licenses three different products that use the Berkeley DB
-technology. Each product offers a distinct level of database support.
-It is not possible to mix-and-match products, that is, each application
-or group of applications must use the same Berkeley DB product.
- All three products are included in the single Open Source distribution of
-Berkeley DB from Sleepycat Software, and building that distribution
-automatically builds all three products. Each product adds services, and
-new interfaces, to the product that precedes it in the list. As a result,
-developers can download Berkeley DB and build an application that does only
-single-user, read-only database access, and later add support for more
-users and more complex database access patterns.
- Users who distribute Berkeley DB must ensure that they are licensed for the
-Berkeley DB interfaces they use. Information on licensing is available directly
-from Sleepycat Software.
- The Berkeley DB Data Store product is an embeddable, high-performance data store. It
-supports multiple concurrent threads of control to read information
-managed by Berkeley DB. When updates are required, only a single process may
-be using the database. That process may be multi-threaded, but only one
-thread of control should be allowed to update the database at any time.
-The Berkeley DB Data Store does no locking, and so provides no guarantees of correct
-behavior if more than one thread of control is updating the database at
-a time.
- The Berkeley DB Data Store product includes the db_create interface, the
-DB handle methods, and the methods returned by DB->cursor.
- The Berkeley DB Data Store is intended for use in single-user or read-only applications
-that can guarantee that no more than one thread of control will ever
-update the database at any time.
- The Berkeley DB Concurrent Data Store product adds multiple-reader, single writer capabilities to
-the Berkeley DB Data Store product, supporting applications that need concurrent updates
-and do not want to implement their own locking protocols. The additional
-interfaces included with the Berkeley DB Concurrent Data Store product are db_env_create, the
-DBENV->open method (using the DB_INIT_CDB flag), and the
-DBENV->close method.
- Berkeley DB Concurrent Data Store is intended for applications that require occasional write access
-to a database that is largely used for reading.
- The Berkeley DB Transactional Data Store product adds full transactional support and recoverability
-to the Berkeley DB Data Store product. This product includes all of the interfaces
-in the Berkeley DB library.
- Berkeley DB Transactional Data Store is intended for applications that require industrial-strength
-database services, including good performance under high-concurrency
-workloads with a mixture of readers and writers, the ability to commit
-or roll back multiple changes to the database at a single instant, and
-the guarantee that even in the event of a catastrophic system or hardware
-failure, any committed database changes will be preserved.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/terrain.html b/bdb/docs/ref/intro/terrain.html
deleted file mode 100644
index f2a7089135c..00000000000
--- a/bdb/docs/ref/intro/terrain.html
+++ /dev/null
@@ -1,248 +0,0 @@
-
-
-
-
-
- The first step in selecting a database system is figuring out what the
-choices are. Decades of research and real-world deployment have produced
-countless systems. We need to organize them somehow to reduce the number
-of options.
- One obvious way to group systems is to use the common labels that
-vendors apply to them. The buzzwords here include "network,"
-"relational," "object-oriented," and "embedded," with some
-cross-fertilization like "object-relational" and "embedded network".
-Understanding the buzzwords is important. Each has some grounding in
-theory, but has also evolved into a practical label for categorizing
-systems that work in a certain way.
- All database systems, regardless of the buzzwords that apply to them,
-provide a few common services. All of them store data, for example.
-We'll begin by exploring the common services that all systems provide,
-and then examine the differences among the different kinds of systems.
- Fundamentally, database systems provide two services.
- The first service is data access. Data access means adding
-new data to the database (inserting), finding data of interest
-(searching), changing data already stored (updating), and removing data
-from the database (deleting). All databases provide these services. How
-they work varies from category to category, and depends on the record
-structure that the database supports.
- Each record in a database is a collection of values. For example, the
-record for a Web site customer might include a name, email address,
-shipping address, and payment information. Records are usually stored
-in tables. Each table holds records of the same kind. For example, the
-customer table at an e-commerce Web site might store the
-customer records for every person who shopped at the site. Often,
-database records have a different structure from the structures or
-instances supported by the programming language in which an application
-is written. As a result, working with records can mean:
- The second service is data management. Data management is
-more complicated than data access. Providing good data management
-services is the hard part of building a database system. When you
-choose a database system to use in an application you build, making sure
-it supports the data management services you need is critical.
- Data management services include allowing multiple users to work on the
-database simultaneously (concurrency), allowing multiple records to be
-changed instantaneously (transactions), and surviving application and
-system crashes (recovery). Different database systems offer different
-data management services. Data management services are entirely
-independent of the data access services listed above. For example,
-nothing about relational database theory requires that the system
-support transactions, but most commercial relational systems do.
- Concurrency means that multiple users can operate on the database at
-the same time. Support for concurrency ranges from none (single-user
-access only) to complete (many readers and writers working
-simultaneously).
- Transactions permit users to make multiple changes appear at once. For
-example, a transfer of funds between bank accounts needs to be a
-transaction because the balance in one account is reduced and the
-balance in the other increases. If the reduction happened before the
-increase, than a poorly-timed system crash could leave the customer
-poorer; if the bank used the opposite order, then the same system crash
-could make the customer richer. Obviously, both the customer and the
-bank are best served if both operations happen at the same instant.
- Transactions have well-defined properties in database systems. They are
-atomic, so that the changes happen all at once or not at all.
-They are consistent, so that the database is in a legal state
-when the transaction begins and when it ends. They are typically
-isolated, which means that any other users in the database
-cannot interfere with them while they are in progress. And they are
-durable, so that if the system or application crashes after
-a transaction finishes, the changes are not lost. Together, the
-properties of atomicity, consistency,
-isolation, and durability are known as the ACID
-properties.
- As is the case for concurrency, support for transactions varies among
-databases. Some offer atomicity without making guarantees about
-durability. Some ignore isolatability, especially in single-user
-systems; there's no need to isolate other users from the effects of
-changes when there are no other users.
- Another important data management service is recovery. Strictly
-speaking, recovery is a procedure that the system carries out when it
-starts up. The purpose of recovery is to guarantee that the database is
-complete and usable. This is most important after a system or
-application crash, when the database may have been damaged. The recovery
-process guarantees that the internal structure of the database is good.
-Recovery usually means that any completed transactions are checked, and
-any lost changes are reapplied to the database. At the end of the
-recovery process, applications can use the database as if there had been
-no interruption in service.
- Finally, there are a number of data management services that permit
-copying of data. For example, most database systems are able to import
-data from other sources, and to export it for use elsewhere. Also, most
-systems provide some way to back up databases and to restore in the
-event of a system failure that damages the database. Many commercial
-systems allow hot backups, so that users can back up
-databases while they are in use. Many applications must run without
-interruption, and cannot be shut down for backups.
- A particular database system may provide other data management services.
-Some provide browsers that show database structure and contents. Some
-include tools that enforce data integrity rules, such as the rule that
-no employee can have a negative salary. These data management services
-are not common to all systems, however. Concurrency, recovery, and
-transactions are the data management services that most database vendors
-support.
- Deciding what kind of database to use means understanding the data
-access and data management services that your application needs. Berkeley DB
-is an embedded database that supports fairly simple data access with a
-rich set of data management services. To highlight its strengths and
-weaknesses, we can compare it to other database system categories.
- Relational databases are probably the best-known database variant,
-because of the success of companies like Oracle. Relational databases
-are based on the mathematical field of set theory. The term "relation"
-is really just a synonym for "set" -- a relation is just a set of
-records or, in our terminology, a table. One of the main innovations in
-early relational systems was to insulate the programmer from the
-physical organization of the database. Rather than walking through
-arrays of records or traversing pointers, programmers make statements
-about tables in a high-level language, and the system executes those
-statements.
- Relational databases operate on tuples, or records, composed
-of values of several different data types, including integers, character
-strings, and others. Operations include searching for records whose
-values satisfy some criteria, updating records, and so on.
- Virtually all relational databases use the Structured Query Language,
-or SQL. This language permits people and computer programs to work with
-the database by writing simple statements. The database engine reads
-those statements and determines how to satisfy them on the tables in
-the database.
- SQL is the main practical advantage of relational database systems.
-Rather than writing a computer program to find records of interest, the
-relational system user can just type a query in a simple syntax, and
-let the engine do the work. This gives users enormous flexibility; they
-do not need to decide in advance what kind of searches they want to do,
-and they do not need expensive programmers to find the data they need.
-Learning SQL requires some effort, but it's much simpler than a
-full-blown high-level programming language for most purposes. And there
-are a lot of programmers who have already learned SQL.
- Object-oriented databases are less common than relational systems, but
-are still fairly widespread. Most object-oriented databases were
-originally conceived as persistent storage systems closely wedded to
-particular high-level programming languages like C++. With the spread
-of Java, most now support more than one programming language, but
-object-oriented database systems fundamentally provide the same class
-and method abstractions as do object-oriented programming languages.
- Many object-oriented systems allow applications to operate on objects
-uniformly, whether they are in memory or on disk. These systems create
-the illusion that all objects are in memory all the time. The advantage
-to object-oriented programmers who simply want object storage and
-retrieval is clear. They need never be aware of whether an object is in
-memory or not. The application simply uses objects, and the database
-system moves them between disk and memory transparently. All of the
-operations on an object, and all its behavior, are determined by the
-programming language.
- Object-oriented databases aren't nearly as widely deployed as relational
-systems. In order to attract developers who understand relational
-systems, many of the object-oriented systems have added support for
-query languages very much like SQL. In practice, though, object-oriented
-databases are mostly used for persistent storage of objects in C++ and
-Java programs.
- The "network model" is a fairly old technique for managing and
-navigating application data. Network databases are designed to make
-pointer traversal very fast. Every record stored in a network database
-is allowed to contain pointers to other records. These pointers are
-generally physical addresses, so fetching the referenced record just
-means reading it from disk by its disk address.
- Network database systems generally permit records to contain integers,
-floating point numbers, and character strings, as well as references to
-other records. An application can search for records of interest. After
-retrieving a record, the application can fetch any referenced record
-quickly.
- Pointer traversal is fast because most network systems use physical disk
-addresses as pointers. When the application wants to fetch a record,
-the database system uses the address to fetch exactly the right string
-of bytes from the disk. This requires only a single disk access in all
-cases. Other systems, by contrast, often must do more than one disk read
-to find a particular record.
- The key advantage of the network model is also its main drawback. The
-fact that pointer traversal is so fast means that applications that do
-it will run well. On the other hand, storing pointers all over the
-database makes it very hard to reorganize the database. In effect, once
-you store a pointer to a record, it is difficult to move that record
-elsewhere. Some network databases handle this by leaving forwarding
-pointers behind, but this defeats the speed advantage of doing a single
-disk access in the first place. Other network databases find, and fix,
-all the pointers to a record when it moves, but this makes
-reorganization very expensive. Reorganization is often necessary in
-databases, since adding and deleting records over time will consume
-space that cannot be reclaimed without reorganizing. Without periodic
-reorganization to compact network databases, they can end up with a
-considerable amount of wasted space.
- Database vendors have two choices for system architecture. They can
-build a server to which remote clients connect, and do all the database
-management inside the server. Alternatively, they can provide a module
-that links directly into the application, and does all database
-management locally. In either case, the application developer needs
-some way of communicating with the database (generally, an Application
-Programming Interface (API) that does work in the process or that
-communicates with a server to get work done).
- Almost all commercial database products are implemented as servers, and
-applications connect to them as clients. Servers have several features
-that make them attractive.
- First, because all of the data is managed by a separate process, and
-possibly on a separate machine, it's easy to isolate the database server
-from bugs and crashes in the application.
- Second, because some database products (particularly relational engines)
-are quite large, splitting them off as separate server processes keeps
-applications small, which uses less disk space and memory. Relational
-engines include code to parse SQL statements, to analyze them and
-produce plans for execution, to optimize the plans, and to execute
-them.
- Finally, by storing all the data in one place and managing it with a
-single server, it's easier for organizations to back up, protect, and
-set policies on their databases. The enterprise databases for large
-companies often have several full-time administrators caring for them,
-making certain that applications run quickly, granting and denying
-access to users, and making backups.
- However, centralized administration can be a disadvantage in some cases.
-In particular, if a programmer wants to build an application that uses
-a database for storage of important information, then shipping and
-supporting the application is much harder. The end user needs to install
-and administer a separate database server, and the programmer must
-support not just one product, but two. Adding a server process to the
-application creates new opportunity for installation mistakes and
-run-time problems.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/what.html b/bdb/docs/ref/intro/what.html
deleted file mode 100644
index c8d12069a57..00000000000
--- a/bdb/docs/ref/intro/what.html
+++ /dev/null
@@ -1,53 +0,0 @@
-
-
-
-
-
- Berkeley DB also provides core database services to developers. These
-services include:
- By combining the page cache, transaction, locking, and logging systems,
-Berkeley DB provides the same services found in much larger, more complex and
-more expensive database systems. Berkeley DB supports multiple simultaneous
-readers and writers and guarantees that all changes are recoverable, even
-in the case of a catastrophic hardware failure during a database update.
- Developers may select some or all of the core database services for any
-access method or database. Therefore, it is possible to choose the
-appropriate storage structure and the right degrees of concurrency and
-recoverability for any application. In addition, some of the systems
-(e.g., the locking subsystem) can be called separately from the Berkeley DB
-access method. As a result, developers can integrate non-database
-objects into their transactional applications using Berkeley DB.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/intro/where.html b/bdb/docs/ref/intro/where.html
deleted file mode 100644
index 45d0dc3ae99..00000000000
--- a/bdb/docs/ref/intro/where.html
+++ /dev/null
@@ -1,39 +0,0 @@
-
-
-
-
-
- Berkeley DB requires only underlying IEEE/ANSI Std 1003.1 (POSIX) system calls and can be
-ported easily to new architectures by adding stub routines to connect
-the native system interfaces to the Berkeley DB POSIX-style system calls.
- Berkeley DB will autoconfigure and run on almost any modern UNIX system, and
-even on most historical UNIX platforms. See
-Building for UNIX systems for
-more information.
- The Berkeley DB distribution includes support for QNX Neutrino. See
-Building for UNIX systems for
-more information.
- The Berkeley DB distribution includes support for VxWorks, via a workspace
-and project files for Tornado 2.0. See
-Building for VxWorks for more
-information.
- The Berkeley DB distribution includes support for Windows/95, Windows/98,
-Windows/NT and Windows/2000, via the MSVC 5 and 6 development
-environments. See Building for
-Windows systems for more information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/java/compat.html b/bdb/docs/ref/java/compat.html
deleted file mode 100644
index 4619ec55794..00000000000
--- a/bdb/docs/ref/java/compat.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- The Berkeley DB Java API has been tested with the
-Sun Microsystems JDK 1.1.3 on SunOS
-5.5, and Sun's JDK 1.1.7, JDK 1.2.2 and JDK 1.3.0 on Linux and
-Windows/NT. It should work with any JDK 1.1, 1.2 or 1.3 (the latter
-two are known as Java 2) compatible environment. IBM's VM 1.3.0 has
-also been tested on Linux.
- The primary requirement of the Berkeley DB Java API is that the target Java
-environment supports JNI (Java Native Interface), rather than another
-method for allowing native C/C++ code to interface to Java. The JNI was
-new in JDK 1.1, but is the most likely interface to be implemented across
-multiple platforms. However, using the JNI means that Berkeley DB will not be
-compatible with Microsoft Visual J++.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/java/conf.html b/bdb/docs/ref/java/conf.html
deleted file mode 100644
index b7eedcaedba..00000000000
--- a/bdb/docs/ref/java/conf.html
+++ /dev/null
@@ -1,82 +0,0 @@
-
-
-
-
-
- Building the Berkeley DB java classes, the examples and the native support
-library is integrated into the normal build process. See
-Configuring
-Berkeley DB and Building for Windows
-for more information.
- We expect that you've already installed the Java JDK or equivalent on
-your system. For the sake of discussion, we'll assume it is in a
-directory called db-VERSION, e.g., you extracted Berkeley DB version 2.3.12
-and you did not change the top-level directory name. The files related
-to Java are in two subdirectories of db-VERSION: java, the java source
-files, and libdb_java, the C++ files that provide the "glue" between
-java and Berkeley DB. The directory tree looks like this:
- This naming conforms to the emerging standard for naming java packages.
-When the java code is built, it is placed into a classes
-subdirectory that is parallel to the src subdirectory.
- For your application to use Berkeley DB successfully, you must set your
-CLASSPATH environment variable to include db-VERSION/java/classes as
-well as the classes in your java distribution. On UNIX, CLASSPATH is
-a colon separated list of directories; on Windows it is separated by
-semicolons. Alternatively, you can set your CLASSPATH to include
-db-VERSION/java/classes/db.jar which is created as a result of the
-build. The db.jar file contains the classes in com.sleepycat.db, it
-does not contain any classes in com.sleepycat.examples.
- On Windows, you will want to set your PATH variable to include:
- On UNIX, you will want to set the LD_LIBRARY_PATH environment variable
-to include the Berkeley DB library installation directory. Of course, the
-standard install directory may have been changed for your site, see your
-system administrator for details. Regardless, if you get a:
- exception when you run, chances are you do not have the library search
-path configured correctly. Different Java interpreters provide
-different error messages if the CLASSPATH value is incorrect, a typical
-error is:
- To ensure that everything is running correctly, you may want to try a
-simple test from the example programs in:
- For example, the sample program:
- will prompt for text input lines which are then stored in a Btree
-database named "access.db" in your current directory. Try giving it a
-few lines of input text and then end-of-file. Before it exits, you
-should see a list of the lines you entered display with data items.
-This is a simple check to make sure the fundamental configuration is
-working correctly.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/java/faq.html b/bdb/docs/ref/java/faq.html
deleted file mode 100644
index 75b9e9f3bdb..00000000000
--- a/bdb/docs/ref/java/faq.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- There are known large-file support bugs under JNI in various releases
-of the JDK. Please upgrade to the latest release of the JDK, and, if
-that does not help, disable big file support using the --disable-bigfile
-configuration option.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/java/program.html b/bdb/docs/ref/java/program.html
deleted file mode 100644
index c454a0910ee..00000000000
--- a/bdb/docs/ref/java/program.html
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
-
-
-
- The Java API closely parallels the Berkeley DB C++ and C interfaces. If you
-are currently using either of those APIs, there will be very little to
-surprise you in the Java API. We have even taken care to make the names
-of classes, constants, methods and arguments identical, where possible,
-across all three APIs.
- An object of type DbDeadlockException is thrown when a deadlock
-would occur.
- An object of type DbMemoryException is thrown when the system
-cannot provide enough memory to complete the operation (the ENOMEM
-system error on UNIX).
- An object of type DbRunRecoveryException, a subclass of
-DbException, is thrown when there is an error that requires a
-recovery of the database, using db_recover.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/am_conv.html b/bdb/docs/ref/lock/am_conv.html
deleted file mode 100644
index 7dbe3e73d47..00000000000
--- a/bdb/docs/ref/lock/am_conv.html
+++ /dev/null
@@ -1,129 +0,0 @@
-
-
-
-
-
- All the Berkeley DB access methods follow the same conventions for locking
-database objects. Applications that do their own locking and also do
-locking via the access methods must be careful to adhere to these
-conventions.
- Whenever a Berkeley DB database is opened, the DB handle is
-assigned a unique locker ID. Unless transactions are specified,
-that ID is used as the locker for all calls that the Berkeley DB methods
-make to the lock subsystem. In order to lock a file, pages in
-the file, or records in the file, we must create a unique ID that
-can be used as the object to be locked in calls to the lock manager.
-Under normal operation, that object is a 28-byte value, created by
-the concatenation of a unique file identifier, a page or record number,
-and an object type (page or record).
- In a transaction-protected environment, database create and delete
-operations are recoverable and single-threaded. This single-threading is
-achieved using a single lock for the entire environment that must be
-acquired before beginning a create or delete operation. In this case,
-the object on which Berkeley DB will lock is a 32-bit unsigned integer with a
-value of 0.
- If applications are using the lock subsystem directly while they are also
-using locking via the access methods, they must take care not to
-inadvertently lock objects that happen to be equal to the unique file IDs
-used to lock files. This is most easily accomplished by using a locker
-ID of a different length than the values used by Berkeley DB.
- All of the access methods other than Queue use a simple
-multiple-reader/single writer page locking scheme. The standard
-read/write locks (DB_LOCK_READ and DB_LOCK_WRITE) and
-conflict matrix, as described in Standard lock modes are used. An operation that returns data (e.g.,
-DB->get, DBcursor->c_get) obtains a read lock on all the pages
-accessed while locating the requested record. When an update operation
-is requested (e.g., DB->put, DBcursor->c_del), the page containing
-the updated (or new) data is write locked. As read-modify-write cycles
-are quite common and are deadlock prone under normal circumstances, the
-Berkeley DB interfaces allow the application to specify the DB_RMW flag,
-which causes operations to immediately obtain a writelock, even though
-they are only reading the data. While this may reduce concurrency
-somewhat, it reduces the probability of deadlock.
- The Queue access method does not hold long term page locks.
-Instead, page locks are held only long enough to locate records or to change
-metadata on a page, and record locks are held for the appropriate duration.
-In the presence of transactions, record locks are held until transaction
-commit.
-For Berkeley DB operations, record locks are held until operation
-completion and for DBC operations, record locks are held until
-subsequent records are returned or the cursor is closed.
- Under non-transaction operation, the access methods do not normally hold
-locks across calls to the Berkeley DB interfaces. The one exception to this
-rule is when cursors are used. As cursors maintain a position in a file,
-they must hold locks across calls and will, in fact, hold locks until the
-cursor is closed. Furthermore, each cursor is assigned its own unique
-locker ID when it is created, so cursor operations can conflict with one
-another. (Each cursor is assigned its own locker ID because Berkeley DB handles
-may be shared by multiple threads of control. The Berkeley DB library cannot
-identify which operations are performed by which threads of control, and
-it must ensure that two different threads of control are not
-simultaneously modifying the same data structure. By assigning each
-cursor its own locker, two threads of control sharing a handle cannot
-inadvertently interfere with each other.
- This has important implications. If a single thread of control opens two
-cursors or uses a combination of cursor and non-cursor operations, these
-operations are performed on behalf of different lockers. Conflicts that
-arise between these different lockers may not cause actual deadlocks, but
-can, in fact, permanently block the thread of control. For example,
-assume that an application creates a cursor and uses it to read record A.
-Now assume a second cursor is opened and the application attempts to write
-record A using the second cursor. Unfortunately, the first cursor has a
-read lock so the second cursor cannot obtain its write lock. However,
-that read lock is held by the same thread of control, so if we block
-waiting for the write lock, the read lock can never be released. This
-might appear to be a deadlock from the application's perspective, but
-Berkeley DB cannot identify it as such because it has no knowledge of which
-lockers belong to which threads of control. For this reason, application
-designers are encouraged to close cursors as soon as they are done with
-them.
- Complicated operations that require multiple cursors (or combinations of
-cursor and non-cursor operations) can be performed in two ways. First,
-they may be performed within a transaction, in which case all operations
-lock on behalf of the designated locker ID. Alternatively, the
-DBcursor->c_dup function duplicates a cursor, using the same locker ID as
-the originating cursor. There is no way to achieve this duplication
-functionality through the DB handle calls, but any DB call can be
-implemented by one or more calls through a cursor.
- When the access methods use transactions, many of these problems disappear.
-The transaction ID is used as the locker ID for all operations performed
-on behalf of the transaction. This means that the application may open
-multiple cursors on behalf of the same transaction and these cursors will
-all share a common locker ID. This is safe because transactions cannot
-span threads of control, so the library knows that two cursors in the same
-transaction cannot modify the database concurrently.
- As mentioned earlier, most of the Berkeley DB access methods use page level
-locking. During Btree traversal, lock-coupling is used to traverse the
-tree. Note that the tree traversal that occurs during an update operation
-can also use lock-coupling; it is not necessary to retain locks on
-internal Btree pages even if the item finally referenced will be updated.
-Even in the presence of transactions, locks obtained on internal pages of
-the Btree may be safely released as the traversal proceeds. This greatly
-improves concurrency. The only time internal locks become crucial is when
-internal pages are split or merged. When traversing duplicate data items
-for a key, the lock on the key value also acts as a lock on all duplicates
-of that key. Therefore, two conflicting threads of control cannot access
-the same duplicate set simultaneously.
- The Recno access method uses a Btree as its underlying data
-representation and follows similar locking conventions. However, as the
-Recno access method must keep track of the number of children for all
-internal pages, it must obtain write locks on all internal pages during
-read and write operations. In the presence of transactions, these locks
-are not released until transaction commit.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/cam_conv.html b/bdb/docs/ref/lock/cam_conv.html
deleted file mode 100644
index b37914890bc..00000000000
--- a/bdb/docs/ref/lock/cam_conv.html
+++ /dev/null
@@ -1,53 +0,0 @@
-
-
-
-
-
- The Berkeley DB Concurrent Data Store product has a different set of conventions for locking. It
-provides multiple reader/single writer semantics, but not per-page locking
-or transaction recoverability. As such, it does its locking entirely at
-the interface to the access methods.
- The object it locks is the file, identified by its unique file number.
-The locking matrix is not one of the two standard lock modes, instead,
-we use a four-lock set, consisting of:
- The IWRITE lock is used for cursors that will be used for updating (IWRITE
-locks are implicitly obtained for write operations through the Berkeley DB
-handles, e.g., DB->put, DB->del). While the cursor is
-reading, the IWRITE lock is held, but as soon as the cursor is about to
-modify the database, the IWRITE is upgraded to a WRITE lock. This upgrade
-blocks until all readers have exited the database. Because only one
-IWRITE lock is allowed at any one time, no two cursors can ever try to
-upgrade to a WRITE lock at the same time, and therefore deadlocks are
-prevented, which is essential as Berkeley DB Concurrent Data Store does not include deadlock
-detection and recovery.
- Applications that need to lock compatibly with Berkeley DB Concurrent Data Store must obey the
-following rules:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/config.html b/bdb/docs/ref/lock/config.html
deleted file mode 100644
index cc0b5248149..00000000000
--- a/bdb/docs/ref/lock/config.html
+++ /dev/null
@@ -1,46 +0,0 @@
-
-
-
-
-
- The DBENV->set_lk_detect function specifies that the deadlock detector
-should be run whenever a lock blocks. This option provides for rapid
-detection of deadlocks at the expense of potentially frequent
-invocations of the deadlock detector. On a fast processor with a highly
-contentious application, where response time is critical, this is a good
-choice. An argument to the DBENV->set_lk_detect function indicates which
-transaction to abort when a deadlock is detected. It can take on any
-one of the following values:
- In general, DB_LOCK_DEFAULT is probably the correct choice. If
-an application has long-running transactions, then
-DB_LOCK_YOUNGEST will guarantee that transactions eventually
-complete, but it may do so at the expense of a large number of aborts.
- The alternative to using the DBENV->set_lk_detect interface is
-to run the deadlock detector manually, using the Berkeley DB
-lock_detect interface.
- The DBENV->set_lk_conflicts function allows you to specify your own locking
-conflicts matrix. This is an advanced configuration option, and rarely
-necessary.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/dead.html b/bdb/docs/ref/lock/dead.html
deleted file mode 100644
index bb77e982285..00000000000
--- a/bdb/docs/ref/lock/dead.html
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
-
-
-
- Practically any application that uses locking may deadlock.
-In nearly all cases, in order to recover from a deadlock, transactions
-must be used, so that an operation that deadlocks mid-way through can
-be undone, leaving the database in a consistent state.
-As the access methods may perform updates on multiple pages during a
-single API call, transactions are necessary even when the application
-makes only single update calls into the database.
-The only exception to this rule is when all the threads accessing
-the database are doing so read-only or when the Concurrent Data Store
-product is used; this product guarantees deadlock-free operation at the
-expense of reduced concurrency.
-Since deadlocks cannot be prevented, Berkeley DB provides the ability to detect
-deadlocks and recover from them gracefully.
- Deadlocks occur when two or more threads of control are blocked waiting
-on each other's forward progress. Consider two transactions, each of
-which wants to modify items A and B. Assume that transaction 1 modifies
-first A and then B, but transaction 2 modifies B then A. Now, assume
-that transaction 1 obtains its writelock on A, but before it obtains its
-writelock on B, it is descheduled and transaction 2 runs. Transaction 2
-successfully acquires its writelock on B, but then blocks when it tries
-to obtain its writelock on A, because transaction 1 already holds a
-writelock on it. This is a deadlock. Transaction 1 cannot make forward
-progress until Transaction 2 releases its lock on B, but Transaction 2
-cannot make forward progress until Transaction 1 releases its lock on A.
- The lock_detect function runs an instance of the Berkeley DB deadlock
-detector. The db_deadlock utility performs deadlock detection by
-calling lock_detect at regular intervals. When a deadlock exists
-in the system, all of the threads of control involved in the deadlock are,
-by definition, waiting on a lock. The deadlock detector examines the
-state of the lock manager and identifies a deadlock, and selects one of
-the participants to abort. (See Configuring locking for a discussion of how a participant is selected).
-The lock on which the selected participant is waiting is identified such
-that the lock_get (or lock_vec) call in which that lock
-was requested will receive an error return of DB_LOCK_DEADLOCK.
-In the access methods, this error return is propagated back through the
-Berkeley DB interface as DB_LOCK_DEADLOCK.
- When an application receives an DB_LOCK_DEADLOCK, the correct action is
-to abort the current transaction, and optionally retry it. Transaction
-support is necessary for recovery from deadlocks. When a deadlock occurs,
-the database may be left in an inconsistent or corrupted state, and any
-database changes already accomplished must be undone before the
-application can proceed further.
- The deadlock detector identifies deadlocks by looking for a cycle in what
-is commonly referred to as its "waits-for" graph. More precisely, the
-deadlock detector reads through the lock table, and finds each object
-currently locked. Each object has a list of transactions or operations
-(hereafter called lockers) that currently hold locks on the object and
-possibly a list of waiting lockers, waiting on the lockers holding it.
-Each object creates one or more partial orderings of lockers. That is,
-for a particular object, every waiting locker comes after every holding
-locker, because that holding locker must release its lock before the
-waiting locker can make forward progress. Conceptually, after each object
-has been examined, the partial orderings are topologically sorted (see
-tsort). If this topological sort reveals any cycles, then the lockers
-forming the cycle are involved in a deadlock. One of the lockers is
-selected for abortion.
- It is possible that aborting a single transaction involved in a deadlock
-is not enough to allow other transactions to make forward progress.
-In this case, the deadlock detector will be called repeatedly.
-Unfortunately, at the time a transaction is selected for abortion,
-there is not enough information available to determine if aborting
-that single transaction will allow forward progress or not. Since
-most applications have few deadlocks, Berkeley DB takes the conservative
-approach, aborting as few transactions as may be necessary to resolve
-the existing deadlocks. In particular, for each unique cycle found
-in the waits-for graph described in the previous paragraph, only one
-transaction is selected for abortion. However, if there are multiple
-cycles, then one transaction from each cycle is selected for abortion.
-Only after the aborting transactions have received the deadlock return
-and aborted their transactions, can it be determined if it is necessary
-to abort other transactions in order to allow forward progress.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/intro.html b/bdb/docs/ref/lock/intro.html
deleted file mode 100644
index b5c85af05b0..00000000000
--- a/bdb/docs/ref/lock/intro.html
+++ /dev/null
@@ -1,89 +0,0 @@
-
-
-
-
-
- The lock subsystem provides interprocess and intraprocess concurrency
-control mechanisms. While the locking system is used extensively by the
-Berkeley DB access methods and transaction system, it may also be used as a
-stand-alone subsystem to provide concurrency control to any set of
-designated resources.
- The lock subsystem is created, initialized, and opened by calls to
-DBENV->open with the DB_INIT_LOCK or DB_INIT_CDB
-flags specified.
- The lock_detect function provides the programmatic interface to
-the Berkeley DB deadlock detector. Whenever two threads of control issue lock
-requests that are not carefully ordered or that require upgrading locks
-(obtaining write locks on objects that are already read-locked), the
-possibility for deadlock arises. A deadlock occurs when two or more
-threads of control are blocked, waiting for actions that another one of
-these blocked threads must take. For example, assume that threads one
-and two have each obtained read locks on object A. Now suppose that both
-threads wish to obtain write locks on object A. Neither thread can be
-granted its writelock (because of the other thread's readlock). Both
-threads block and will never unblock because the event for which they are
-waiting can never happen.
- The deadlock detector examines all the locks held in the environment and
-identifies situations where no thread can make forward progress. It then
-selects one of the participants in the deadlock (according to the argument
-that was specified to DBENV->set_lk_detect) and forces it to return
-the value DB_LOCK_DEADLOCK, which indicates that a deadlock occurred.
-The thread receiving such an error should abort its current transaction,
-or simply release all its locks if it is not running in a transaction,
-and retry the operation.
- The lock_vec interface is used to acquire and release locks.
- Two additional interfaces, lock_get and lock_put, are
-provided. These interfaces are simpler front-ends to the lock_vec
-functionality, where lock_get acquires a lock, and
-lock_put releases a lock that was acquired using lock_get
-or lock_vec.
- It is up to the application to specify lockers and objects appropriately.
-When used with the Berkeley DB access methods, these lockers and objects are
-handled completely internally, but an application using the lock manager
-directly must either use the same conventions as the access methods or
-define its own convention to which it adheres. If the application is
-using the access methods with locking at the same time that it is calling
-the lock manager directly, the application must follow a convention that
-is compatible with the access methods' use of the locking subsystem. See
-Access method locking conventions
-for more information.
- The lock_id function returns a unique ID which may safely be used
-as the locker parameter to the lock_vec interface. The access
-methods use lock_id to generate unique lockers for the cursors
-associated with a database.
- The lock_vec function performs any number of lock operations
-atomically. It also provides the ability to release all locks held by a
-particular locker and release all the locks on a particular object.
-Performing multiple lock operations atomically is useful in performing
-Btree traversals where you want to acquire a lock on a child page and once
-acquired, immediately release the lock on its parent (this is
-traditionally referred to as "lock-coupling"). Using lock_vec
-instead of separate calls to lock_put and lock_get reduces
-the synchronization overhead between multiple threads or processes.
- The three interfaces, lock_get, lock_put and lock_vec,
-are fully compatible, and may be used interchangeably.
- All locks explicitly requested by an application should be released via
-calls to lock_put or lock_vec.
- The lock_stat function returns information about the status of
-the lock subsystem. It is the programmatic interface used by the
-db_stat utility.
- The locking subsystem is closed by the call to DBENV->close.
- Finally, the entire locking subsystem may be discarded using the
-DBENV->remove interface.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/max.html b/bdb/docs/ref/lock/max.html
deleted file mode 100644
index 23622909035..00000000000
--- a/bdb/docs/ref/lock/max.html
+++ /dev/null
@@ -1,88 +0,0 @@
-
-
-
-
-
- The lock system is sized using the following three functions:
- The DBENV->set_lk_max_locks, DBENV->set_lk_max_lockers
-and DBENV->set_lk_max_objects functions specify, respectively, the
-maximum number of locks, lockers and locked objects supported by the
-lock subsystem. The maximum number of locks is the number of locks that
-can be simultaneously requested in the system. The maximum number of
-lockers is the number of lockers that can simultaneously request locks
-in the system. The maximum number of lock objects is the number of
-objects that can simultaneously be locked in the system. Selecting
-appropriate values requires an understanding of your application and
-its databases. If the values are too small, then requests for locks in
-an application will fail. If the values are too large, then the locking
-subsystem will consume more resources than is necessary. It is better
-to err in the direction of allocating too many locks, lockers and
-objects as increasing the number of locks does not require large amounts
-of additional resources.
- The recommended algorithm for selecting the maximum number of locks,
-lockers and lock objects, is to run the application under stressful
-conditions and then review the lock system's statistics to determine
-the maximum number of locks, lockers and lock objects that were used.
-Then, double these values for safety. However, in some large
-applications, finer granularity of control is necessary in order to
-minimize the size of the lock subsystem.
- The maximum number of lockers can be estimated as follows:
- The maximum number of lock objects needed can be estimated as follows:
- For all access methods, you should then add an additional lock object
-per database, for the database's metadata page.
- The maximum number of locks required by an application cannot be easily
-estimated. It is possible to calculate a maximum number of locks by
-multiplying the maximum number of lockers, times the maximum number of
-lock objects, times two (two for the two possible lock modes for each
-object, read and write). However, this is a pessimal value, and real
-applications are unlikely to actually need that many locks. Review of
-the lock subsystem statistics is the best way to determine this value.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/nondb.html b/bdb/docs/ref/lock/nondb.html
deleted file mode 100644
index 4fb37d6d7b0..00000000000
--- a/bdb/docs/ref/lock/nondb.html
+++ /dev/null
@@ -1,50 +0,0 @@
-
-
-
-
-
- The locking subsystem is useful outside the context of Berkeley DB. It can be
-used to manage concurrent access to any collection of either ephemeral or
-persistent objects. That is, the lock region can persist across
-invocations of an application, so it can be used to provide long-term
-locking (e.g., conference room scheduling).
- In order to use the locking subsystem in such a general way, the
-applications must adhere to a convention for naming objects and lockers.
-Consider the conference room scheduling problem described above. Assume
-there are three conference rooms and that we wish to schedule them in
-half-hour intervals.
- The scheduling application must then select a way to identify each
-conference room/time slot combination. In this case, we could describe
-the objects being locker as bytestrings consisting of the conference room
-name, the date on which it is needed, and the beginning of the appropriate
-half-hour slot.
- Lockers are 32-bit numbers, so we might choose to use the User ID of the
-individual running the scheduling program. To schedule half-hour slots,
-all the application need do is issue a lock_get call for the
-appropriate locker/object pair. To schedule a longer slot, the
-application would issue a lock_vec call with one lock_get
-operation per half-hour up to the total length. If the lock_vec
-call fails, the application would have to release the parts of the time
-slot that were obtained.
- To cancel a reservation, the application would make the appropriate
-lock_put calls. To reschedule a reservation, the lock_get
-and lock_put calls could all be made inside of a single
-lock_vec call. The output of lock_stat could be
-post-processed into a human-readable schedule of conference room use.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/notxn.html b/bdb/docs/ref/lock/notxn.html
deleted file mode 100644
index 16b00cf66bf..00000000000
--- a/bdb/docs/ref/lock/notxn.html
+++ /dev/null
@@ -1,46 +0,0 @@
-
-
-
-
-
- If an application runs with locking specified, but not transactions (e.g.,
-DBENV->open is called with DB_INIT_LOCK or
-DB_INIT_CDB specified, but not DB_INIT_TXN), locks are
-normally acquired during each Berkeley DB operation and released before the
-operation returns to the caller. The only exception is in the case of
-cursor operations. As cursors identify a particular position in a file,
-a cursor must retain a read-lock across cursor calls to make sure that
-that position is uniquely identifiable during the next cursor call,
-because an operation using DB_CURRENT must reference the same
-record as the previous cursor call. Such cursor locks cannot be released
-until either the cursor is reset using the DB_GET_BOTH,
-DB_SET, DB_SET_RANGE, DB_KEYFIRST, or
-DB_KEYLAST functionality, in which case a new cursor lock is
-established, or the cursor is closed. As a result, application designers
-are encouraged to close cursors as soon as possible.
- It is important to realize that concurrent applications that use locking
-must ensure that two concurrent threads do not interfere with each other.
-However, as Btree and Hash access method page splits can occur at any
-time, there is virtually no way to guarantee that an application which
-writes the database cannot deadlock. Applications running without the
-protection of transactions may deadlock, and when they do so, can leave
-the database in an inconsistent state. Applications that need concurrent
-access, but not transactions, are more safely implemented using the Berkeley DB Concurrent Data Store
-Product.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/page.html b/bdb/docs/ref/lock/page.html
deleted file mode 100644
index a7e43b3af66..00000000000
--- a/bdb/docs/ref/lock/page.html
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-
-
-
- Under normal operation, the access methods use page locking. The pagesize
-of a database is set when the database is created and may be specified by
-calling the DB->set_pagesize function. If not specified, the Berkeley DB
-package tries to select a pagesize that will provide the best I/O
-performance by setting the page size equal to the block size of the
-underlying file system.
- In the Btree access method, Berkeley DB uses a technique called lock coupling
-to improve concurrency. The traversal of a Btree requires reading a page,
-searching that page to determine which page to search next and then
-repeating this process on the next page. Once a page has been searched,
-it will never be accessed again for this operation, unless a page split
-is required. To improve concurrency in the tree, once the next page to
-read/search has been determined, that page is locked, and then atomically
-(i.e., without relinquishing control of the lock manager) the original
-page lock is released.
- As the Recno access method is built upon Btree, it too uses lock coupling
-for read operations. However, as the Recno access method must maintain
-a count of records on its internal pages, it cannot lock couple during
-write operations. Instead, it retains write locks on all internal pages
-during every update operation. For this reason, it is not possible to
-have high concurrency in the Recno access method in the presence of write
-operations.
- The Queue access method only uses short term page locks. That is, a page
-lock is released prior to requesting another page lock. Record locks are
-used for transaction isolation. The provides a high degree of concurrency
-for write operations. A metadata page is used to keep track of the head
-and tail of the queue. This page is never locked during other locking or
-I/O operations.
- The Hash access method does not have such traversal issues, but because
-it implements dynamic hashing, it must always refer to its metadata while
-computing a hash function. This metadata is stored on a special page in
-the hash database. This page must therefore be read locked on every
-operation. Fortunately, it need only be write locked when new pages are
-allocated to the file, which happens in three cases: 1) a hash bucket
-becomes full and needs to split, 2) a key or data item is too large to
-fit on a normal page, and 3) the number of duplicate items for a fixed
-key becomes sufficiently large that they are moved to an auxiliary page.
-In this case, the access method must obtain a write lock on the metadata
-page, thus requiring that all readers be blocked from entering the tree
-until the update completes.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/stdmode.html b/bdb/docs/ref/lock/stdmode.html
deleted file mode 100644
index ca1cd6b0bdd..00000000000
--- a/bdb/docs/ref/lock/stdmode.html
+++ /dev/null
@@ -1,61 +0,0 @@
-
-
-
-
-
- The Berkeley DB locking protocol is described by a conflict matrix. A conflict
-matrix is an n x n array where n is the number of different lock modes
-supported, and the (i, j)th entry of the array indicates whether a lock of
-mode i conflicts with a lock of mode j.
- The Berkeley DB include files declare two commonly used conflict arrays:
- The number of modes associated with each matrix are DB_LOCK_RW_N and
-DB_LOCK_RIW_N, respectively.
- In addition, the Berkeley DB include file defines the type db_lockmode_t,
-which is the type of the lock modes used with the standard tables above:
- As an example, consider the basic multiple-reader/single writer conflict
-matrix described by db_rw_conflicts. In the following
-example (and in the appropriate file), a 1 represents a conflict (i.e.,
-do not grant the lock if the indicated lock is held) and a 0 indicates
-that it is OK to grant the lock.
- The rows indicate the lock that is held and the columns indicate the lock
-that is requested.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/lock/twopl.html b/bdb/docs/ref/lock/twopl.html
deleted file mode 100644
index 6cf112c0979..00000000000
--- a/bdb/docs/ref/lock/twopl.html
+++ /dev/null
@@ -1,50 +0,0 @@
-
-
-
-
-
- Berkeley DB uses a locking protocol called two-phase locking. This is the
-traditional protocol used in conjunction with lock-based transaction
-systems.
- In a two-phase locking (2PL) system, transactions are broken up into two
-distinct phases. During the first phase, the transaction only acquires
-locks. During the second phase, the transaction only releases locks.
-More formally, once a transaction releases a lock, it may not acquire any
-additional locks. Practically, this translates into a system where locks
-are acquired as they are needed throughout a transaction and retained
-until the transaction ends, either by committing or aborting. In Berkeley DB,
-locks are released during txn_abort or txn_commit. The
-only exception to this protocol occurs when we use lock-coupling to
-traverse a data structure. If the locks are held only for traversal
-purposes, then the locks may be released before transaction commit or
-abort.
- For applications, the implications of 2PL are that long-running
-transactions will hold locks for a long time. When designing
-applications, lock contention should be considered. In order to reduce
-the probability of deadlock and achieve the best level of concurrency
-possible, the following guidelines are helpful.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/log/config.html b/bdb/docs/ref/log/config.html
deleted file mode 100644
index f3c94889312..00000000000
--- a/bdb/docs/ref/log/config.html
+++ /dev/null
@@ -1,40 +0,0 @@
-
-
-
-
-
- The two aspects of logging that may be configured are the size of log
-files on disk and the size of the log buffer in memory. The
-DBENV->set_lg_max interface specifies the individual log file
-size for all of the applications sharing the Berkeley DB environment. Setting
-the log file size is largely a matter of convenience, and a reflection
-of the application's preferences in backup media and frequency.
-However, setting the log file size too low can potentially cause
-problems as it would be possible to run out of log sequence numbers,
-which requires a full archival and application restart to reset. See
-the Log file limits section for more
-information.
- The DBENV->set_lg_bsize interface specifies the size of the
-in-memory log buffer, in bytes. Log information is stored in memory
-until the buffer fills up or transaction commit forces the buffer to be
-written to disk. Larger buffer sizes can significantly increase
-throughput in the presence of long running transactions, highly
-concurrent applications, or transactions producing large amounts of
-data. By default, the buffer is 32KB.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/log/intro.html b/bdb/docs/ref/log/intro.html
deleted file mode 100644
index 0c41c17efa0..00000000000
--- a/bdb/docs/ref/log/intro.html
+++ /dev/null
@@ -1,58 +0,0 @@
-
-
-
-
-
- The logging subsystem is the logging facility used by Berkeley DB. It is
-largely Berkeley DB specific, although it is potentially useful outside of
-the Berkeley DB package for applications wanting write-ahead logging support.
-Applications wanting to use the log for purposes other than logging file
-modifications based on a set of open file descriptors will almost
-certainly need to make source code modifications to the Berkeley DB code
-base.
- A log can be shared by any number of threads of control. The
-DBENV->open interface is used to open a log. When the log is no
-longer in use, it should be closed, using the DBENV->close
-interface.
- Individual log entries are identified by log sequence numbers. Log
-sequence numbers are stored in an opaque object, a DB_LSN.
- The log_put interface is used to append new log records to the
-log. Optionally, the DB_CHECKPOINT flag can be used to output
-a checkpoint log record (indicating that the log is consistent to that
-point and recoverable after a system or application failure), as well
-as open-file information. The log_get interface is used to
-retrieve log records from the log.
- There are additional interfaces for integrating the log subsystem with a
-transaction processing system:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/log/limits.html b/bdb/docs/ref/log/limits.html
deleted file mode 100644
index d34e5a81339..00000000000
--- a/bdb/docs/ref/log/limits.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
-
- Log file names and sizes impose a limit on how long databases may be
-used in a Berkeley DB database environment. It is quite unlikely that an
-application will reach this limit, however, if the limit is reached,
-the Berkeley DB environment's databases must be dumped and reloaded.
- The log file name consists of log. followed by 10 digits, with
-a maximum of 2,000,000,000 log files. Consider an application performing
-6000 transactions per second, for 24 hours a day, logged into 10MB log
-files, where each transaction is logging approximately 500 bytes of data.
-The calculation:
- indicates that the system will run out of log file names in roughly 221
-years.
- There is no way to reset the log file name space in Berkeley DB. If your
-application is reaching the end of its log file name space, you must:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/mp/config.html b/bdb/docs/ref/mp/config.html
deleted file mode 100644
index cf311516de3..00000000000
--- a/bdb/docs/ref/mp/config.html
+++ /dev/null
@@ -1,55 +0,0 @@
-
-
-
-
-
- There are two interfaces used for configuring the memory pool.
- The most important tuning parameter for almost all applications, including
-Berkeley DB applications, is the size of the pool. There are two ways to
-specify the pool size. First, calling the DBENV->set_cachesize function
-specifies the pool size for all of the applications sharing the Berkeley DB
-environment. Second, by calling the DB->set_cachesize function. The
-latter only specifies a pool size for the specific database. Note, it is
-meaningless to call DB->set_cachesize for a database opened inside
-of a Berkeley DB environment, since the environment pool size will override any
-pool size specified for a single database. For information on tuning the
-Berkeley DB cache size, see Selecting
-a cache size.
- The second memory pool configuration interface specifies the maximum size
-of backing files to map into the process address space instead of copying
-pages through the local cache. Only read-only database files can be
-mapped into process memory. Because of the requirements of the Berkeley DB
-transactional implementation, log records describing database changes must
-be written to disk before the actual database changes. As mapping
-read-write database files into process memory would permit the underlying
-operating system to write modified database changes at will, it is not
-supported.
- Mapping files into the process address space can result in
-better-than-usual performance, as available virtual memory is normally
-much larger than the local cache, and page faults are faster than page
-copying on many systems. However, in the presence of limited virtual
-memory it can cause resource starvation, and in the presence of large
-databases, it can result in immense process sizes.
- To specify that no files are to be mapped into the process address space,
-specify the DB_NOMMAP flag to the DBENV->set_flags interface.
-To specify that any individual file should not be mapped into the process
-address space, specify the DB_NOMMAP flag to the
-memp_fopen interface. To limit the size of files mapped into the
-process address space, use the DBENV->set_mp_mmapsize function.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/mp/intro.html b/bdb/docs/ref/mp/intro.html
deleted file mode 100644
index 2b52a5775ce..00000000000
--- a/bdb/docs/ref/mp/intro.html
+++ /dev/null
@@ -1,59 +0,0 @@
-
-
-
-
-
- The memory pool subsystem is the general-purpose shared memory buffer pool
-used by Berkeley DB. This module is useful outside of the Berkeley DB package for
-processes that require page-oriented, cached, shared file access.
- A memory pool is a shared memory cache shared by any number of processes
-and threads within processes. The DBENV->open interface opens, and
-optionally creates, a memory pool. When that pool is no longer in use,
-it should be closed, using the DBENV->close interface.
- The memp_fopen interface opens an underlying file within the
-memory pool. When that file is no longer in use, it should be closed,
-using the memp_fclose interface. The memp_fget interface
-is used to retrieve pages from files in the pool. All retrieved pages
-must be subsequently returned using the memp_fput interface. At
-the time that pages are returned, they may be marked dirty, which
-causes them to be written to the backing disk file before being discarded
-from the pool. If there is insufficient room to bring a new page in the
-pool, a page is selected to be discarded from the pool. If that page is
-dirty, it is first written to the backing file. The page is selected
-using a somewhat modified least-recently-used algorithm. Pages in files
-may also be explicitly marked clean or dirty using the memp_fset
-interface. All dirty pages in the pool from any underlying file may also
-be flushed as a group using the memp_fsync interface.
- There are additional interfaces for manipulating the entire memory pool:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/perl/intro.html b/bdb/docs/ref/perl/intro.html
deleted file mode 100644
index da5d93a6af7..00000000000
--- a/bdb/docs/ref/perl/intro.html
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
-
-
-
- The original Perl module for Berkeley DB was DB_File, which was written to
-interface to Berkeley DB version 1.85. The newer Perl module for Berkeley DB is
-BerkeleyDB, which was written to interface to version 2.0 and subsequent
-releases. Because Berkeley DB version 2.X has a compatibility API for version
-1.85, you can (and should!) build DB_File using version 2.X of Berkeley DB,
-although DB_File will still only support the 1.85 functionality.
- DB_File is distributed with the standard Perl source distribution (look
-in the directory "ext/DB_File"). You can find both DB_File and BerkeleyDB
-on CPAN, the Comprehensive Perl Archive Network of mirrored FTP sites.
-The master CPAN site is
-ftp://ftp.funet.fi/.
- Versions of both BerkeleyDB and DB_File that are known to work correctly
-with each release of Berkeley DB are included in the distributed Berkeley DB source
-tree, in the subdirectories perl.BerkeleyDB and
-perl.DB_File. Each of those directories contains a
-README file with instructions on installing and using those
-modules.
- The Perl interface is not maintained by Sleepycat Software. Questions
-about the DB_File and BerkeleyDB modules are best asked on the Usenet
-newsgroup comp.lang.perl.modules.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/pindex.src b/bdb/docs/ref/pindex.src
deleted file mode 100644
index 0e122ceb29e..00000000000
--- a/bdb/docs/ref/pindex.src
+++ /dev/null
@@ -1,212 +0,0 @@
-__APIREL__/ref/am/close.html#2 @closing a database
-__APIREL__/ref/am/count.html#2 @counting data items for a key
-__APIREL__/ref/am/curclose.html#2 @closing a cursor
-__APIREL__/ref/am/curclose.html#3 closing a @cursor
-__APIREL__/ref/am/curdel.html#2 @deleting records with a cursor
-__APIREL__/ref/am/curdel.html#3 deleting records with a @cursor
-__APIREL__/ref/am/curdup.html#2 @duplicating a cursor
-__APIREL__/ref/am/curdup.html#3 duplicating a @cursor
-__APIREL__/ref/am/curget.html#2 @retrieving records with a cursor
-__APIREL__/ref/am/curget.html#3 retrieving records with a @cursor
-__APIREL__/ref/am/curput.html#2 @storing records with a cursor
-__APIREL__/ref/am/curput.html#3 storing records with a @cursor
-__APIREL__/ref/am/cursor.html#2 database @cursors
-__APIREL__/ref/am/delete.html#2 @deleting records
-__APIREL__/ref/am/error.html#2 @error handling
-__APIREL__/ref/am/get.html#2 @retrieving records
-__APIREL__/ref/am/join.html#2 logical @join
-__APIREL__/ref/am/open.html#2 @opening a database
-__APIREL__/ref/am/partial.html#2 @partial record storage and retrieval
-__APIREL__/ref/am/put.html#2 @storing records
-__APIREL__/ref/am/stability.html#2 @cursor stability
-__APIREL__/ref/am/stability.html#3 cursor @stability
-__APIREL__/ref/am/stat.html#2 database @statistics
-__APIREL__/ref/am/sync.html#2 flushing the database @cache
-__APIREL__/ref/am/upgrade.html#2 @upgrading databases
-__APIREL__/ref/am/verify.html#2 database @verification
-__APIREL__/ref/am/verify.html#3 database @salvage
-__APIREL__/ref/am/verify.html#4 recovering @corrupted databases
-__APIREL__/ref/am_conf/bt_compare.html#2 specifying a Btree @comparison function
-__APIREL__/ref/am_conf/bt_recnum.html#2 retrieving Btree records by @number
-__APIREL__/ref/am_conf/byteorder.html#2 selecting a @byte order
-__APIREL__/ref/am_conf/cachesize.html#2 selecting a @cache size
-__APIREL__/ref/am_conf/dup.html#2 @duplicate data items
-__APIREL__/ref/am_conf/extentsize.html#2 selecting a Queue @extent size
-__APIREL__/ref/am_conf/h_ffactor.html#2 page @fill factor
-__APIREL__/ref/am_conf/h_hash.html#2 specifying a database @hash
-__APIREL__/ref/am_conf/h_nelem.html#2 @hash table size
-__APIREL__/ref/am_conf/intro.html#2 @access methods
-__APIREL__/ref/am_conf/logrec.html#2 logical @record numbers
-__APIREL__/ref/am_conf/pagesize.html#2 selecting a @page size
-__APIREL__/ref/am_conf/re_source.html#2 @text backing files
-__APIREL__/ref/am_conf/recno.html#2 managing @record-based databases
-__APIREL__/ref/am_conf/renumber.html#2 logically renumbering @records
-__APIREL__/ref/am_conf/select.html#2 selecting an @access method
-__APIREL__/ref/arch/apis.html#2 programmatic @APIs
-__APIREL__/ref/arch/utilities.html#2 @utilities
-__APIREL__/ref/build_unix/aix.html#2 @AIX
-__APIREL__/ref/build_unix/conf.html#2 @configuring Berkeley DB for UNIX systems
-__APIREL__/ref/build_unix/conf.html#3 configuring Berkeley DB for @UNIX systems
-__APIREL__/ref/build_unix/conf.html#4 configuring without large @file support
-__APIREL__/ref/build_unix/conf.html#--disable-bigfile Configuring Berkeley DB@--disable-bigfile
-__APIREL__/ref/build_unix/conf.html#5 configuring Berkeley DB @1.85 API compatibility
-__APIREL__/ref/build_unix/conf.html#--enable-compat185 Configuring Berkeley DB@--enable-compat185
-__APIREL__/ref/build_unix/conf.html#6 configuring the @C++ API
-__APIREL__/ref/build_unix/conf.html#--enable-cxx Configuring Berkeley DB@--enable-cxx
-__APIREL__/ref/build_unix/conf.html#--enable-debug Configuring Berkeley DB@--enable-debug
-__APIREL__/ref/build_unix/conf.html#--enable-debug_rop Configuring Berkeley DB@--enable-debug_rop
-__APIREL__/ref/build_unix/conf.html#--enable-debug_wop Configuring Berkeley DB@--enable-debug_wop
-__APIREL__/ref/build_unix/conf.html#--enable-diagnostic Configuring Berkeley DB@--enable-diagnostic
-__APIREL__/ref/build_unix/conf.html#7 building a utility to dump Berkeley DB @1.85 databases
-__APIREL__/ref/build_unix/conf.html#--enable-dump185 Configuring Berkeley DB@--enable-dump185
-__APIREL__/ref/build_unix/conf.html#8 configuring @shared libraries
-__APIREL__/ref/build_unix/conf.html#9 configuring @dynamic shared libraries
-__APIREL__/ref/build_unix/conf.html#--enable-dynamic Configuring Berkeley DB@--enable-dynamic
-__APIREL__/ref/build_unix/conf.html#10 configuring the @Java API
-__APIREL__/ref/build_unix/conf.html#--enable-java Configuring Berkeley DB@--enable-java
-__APIREL__/ref/build_unix/conf.html#--enable-posixmutexes Configuring Berkeley DB@--enable-posixmutexes
-__APIREL__/ref/build_unix/conf.html#11 configuring a @RPC client/server
-__APIREL__/ref/build_unix/conf.html#--enable-rpc Configuring Berkeley DB@--enable-rpc
-__APIREL__/ref/build_unix/conf.html#--enable-shared Configuring Berkeley DB@--enable-shared
-__APIREL__/ref/build_unix/conf.html#12 configuring the @Tcl API
-__APIREL__/ref/build_unix/conf.html#--enable-tcl Configuring Berkeley DB@--enable-tcl
-__APIREL__/ref/build_unix/conf.html#13 configuring the @test suite
-__APIREL__/ref/build_unix/conf.html#--enable-test Configuring Berkeley DB@--enable-test
-__APIREL__/ref/build_unix/conf.html#--enable-uimutexes Configuring Berkeley DB@--enable-uimutexes
-__APIREL__/ref/build_unix/conf.html#--enable-umrw Configuring Berkeley DB@--enable-umrw
-__APIREL__/ref/build_unix/conf.html#--with-tcl=DIR Configuring Berkeley DB@--with-tcl=DIR
-__APIREL__/ref/build_unix/flags.html#2 changing @compile or load options
-__APIREL__/ref/build_unix/flags.html#3 changing compile or @load options
-__APIREL__/ref/build_unix/freebsd.html#2 @FreeBSD
-__APIREL__/ref/build_unix/hpux.html#2 @HP-UX
-__APIREL__/ref/build_unix/install.html#2 @installing Berkeley DB for UNIX systems
-__APIREL__/ref/build_unix/intro.html#2 @building for UNIX
-__APIREL__/ref/build_unix/irix.html#2 @IRIX
-__APIREL__/ref/build_unix/linux.html#2 @Linux
-__APIREL__/ref/build_unix/notes.html#2 @building for UNIX FAQ
-__APIREL__/ref/build_unix/notes.html#3 building for @UNIX FAQ
-__APIREL__/ref/build_unix/osf1.html#2 @OSF/1
-__APIREL__/ref/build_unix/qnx.html#2 @QNX
-__APIREL__/ref/build_unix/sco.html#2 @SCO
-__APIREL__/ref/build_unix/shlib.html#2 @shared libraries
-__APIREL__/ref/build_unix/solaris.html#2 @Solaris
-__APIREL__/ref/build_unix/sunos.html#2 @SunOS
-__APIREL__/ref/build_unix/test.html#2 running the @test suite under UNIX
-__APIREL__/ref/build_unix/ultrix.html#2 @Ultrix
-__APIREL__/ref/build_vxworks/faq.html#2 @building for VxWorks FAQ
-__APIREL__/ref/build_vxworks/faq.html#3 building for @VxWorks FAQ
-__APIREL__/ref/build_vxworks/intro.html#2 @building for VxWorks
-__APIREL__/ref/build_vxworks/notes.html#2 @VxWorks notes
-__APIREL__/ref/build_win/faq.html#2 @building for Windows FAQ
-__APIREL__/ref/build_win/faq.html#3 building for @Windows FAQ
-__APIREL__/ref/build_win/intro.html#2 @building for Win32
-__APIREL__/ref/build_win/notes.html#2 @Windows notes
-__APIREL__/ref/build_win/test.html#2 running the @test suite under Windows
-__APIREL__/ref/build_win/test.html#3 running the test suite under @Windows
-__APIREL__/ref/cam/intro.html#2 @Concurrent Data Store
-__APIREL__/ref/debug/common.html#2 @debugging applications
-__APIREL__/ref/distrib/layout.html#2 @source code layout
-__APIREL__/ref/dumpload/text.html#2 loading @text into databases
-__APIREL__/ref/dumpload/utility.html#2 dumping/loading @text to/from databases
-__APIREL__/ref/env/create.html#2 database @environment
-__APIREL__/ref/env/naming.html#2 file @naming
-__APIREL__/ref/env/naming.html#db_home File naming@db_home
-__APIREL__/ref/env/naming.html#DB_HOME File naming@DB_HOME
-__APIREL__/ref/env/naming.html#DB_CONFIG File naming@DB_CONFIG
-__APIREL__/ref/env/remote.html#2 remote @filesystems
-__APIREL__/ref/env/security.html#2 @security
-__APIREL__/ref/intro/products.html#2 Sleepycat Software's Berkeley DB @products
-__APIREL__/ref/install/file.html#2 @/etc/magic
-__APIREL__/ref/install/file.html#3 @file utility
-__APIREL__/ref/java/compat.html#2 @Java compatibility
-__APIREL__/ref/java/conf.html#2 @Java configuration
-__APIREL__/ref/java/faq.html#2 Java @FAQ
-__APIREL__/ref/java/faq.html#3 @Java FAQ
-__APIREL__/ref/lock/am_conv.html#2 @locking conventions
-__APIREL__/ref/lock/cam_conv.html#2 Berkeley DB Concurrent Data Store @locking conventions
-__APIREL__/ref/lock/config.html#2 @locking configuration
-__APIREL__/ref/lock/dead.html#2 @deadlocks
-__APIREL__/ref/lock/intro.html#2 @locking introduction
-__APIREL__/ref/lock/max.html#2 sizing the @locking subsystem
-__APIREL__/ref/lock/nondb.html#2 @locking and non-Berkeley DB applications
-__APIREL__/ref/lock/notxn.html#2 @locking without transactions
-__APIREL__/ref/lock/page.html#2 page-level @locking
-__APIREL__/ref/lock/stdmode.html#2 standard @lock modes
-__APIREL__/ref/lock/twopl.html#2 two-phase @locking
-__APIREL__/ref/log/config.html#2 @logging configuration
-__APIREL__/ref/log/intro.html#2 @logging introduction
-__APIREL__/ref/log/limits.html#2 @log file limits
-__APIREL__/ref/mp/config.html#2 @memory pool configuration
-__APIREL__/ref/perl/intro.html#2 @Perl
-__APIREL__/ref/program/appsignals.html#2 application @signal handling
-__APIREL__/ref/program/byteorder.html#2 @byte ordering
-__APIREL__/ref/program/byteorder.html#3 byte @endian
-__APIREL__/ref/program/compatible.html#2 @interface compatibility
-__APIREL__/ref/program/dbsizes.html#2 database @limits
-__APIREL__/ref/program/diskspace.html#2 @disk space requirements
-__APIREL__/ref/program/environ.html#2 @environment variables
-__APIREL__/ref/program/errorret.html#2 @error returns
-__APIREL__/ref/program/errorret.html#3 @error name space
-__APIREL__/ref/program/errorret.html#DB_NOTFOUND Error returns to applications@DB_NOTFOUND
-__APIREL__/ref/program/errorret.html#DB_KEYEMPTY Error returns to applications@DB_KEYEMPTY
-__APIREL__/ref/program/errorret.html#DB_LOCK_DEADLOCK Error returns to applications@DB_LOCK_DEADLOCK
-__APIREL__/ref/program/errorret.html#DB_LOCK_NOTGRANTED Error returns to applications@DB_LOCK_NOTGRANTED
-__APIREL__/ref/program/errorret.html#DB_RUNRECOVERY Error returns to applications@DB_RUNRECOVERY
-__APIREL__/ref/program/mt.html#2 building @threaded applications
-__APIREL__/ref/program/namespace.html#2 Berkeley DB library @name spaces
-__APIREL__/ref/program/scope.html#2 Berkeley DB handle @scope
-__APIREL__/ref/program/scope.html#3 Berkeley DB @free-threaded handles
-__APIREL__/ref/rpc/client.html#2 @RPC client
-__APIREL__/ref/rpc/server.html#2 @RPC server
-__APIREL__/ref/sendmail/intro.html#2 @Sendmail
-__APIREL__/ref/tcl/intro.html#2 loading Berkeley DB with @Tcl
-__APIREL__/ref/tcl/faq.html#2 Tcl @FAQ
-__APIREL__/ref/tcl/faq.html#3 @Tcl FAQ
-__APIREL__/ref/tcl/program.html#2 @Tcl API programming notes
-__APIREL__/ref/tcl/using.html#2 using Berkeley DB with @Tcl
-__APIREL__/ref/test/run.html#2 running the @test suite
-__APIREL__/ref/transapp/admin.html#2 administering @transaction protected applications
-__APIREL__/ref/transapp/archival.html#2 archival in @transaction protected applications
-__APIREL__/ref/transapp/archival.html#3 @catastrophic recovery
-__APIREL__/ref/transapp/checkpoint.html#2 checkpoints in @transaction protected applications
-__APIREL__/ref/transapp/deadlock.html#2 deadlock detection in @transaction protected applications
-__APIREL__/ref/transapp/filesys.html#2 recovery and @filesystem operations
-__APIREL__/ref/transapp/intro.html#2 @Transactional Data Store
-__APIREL__/ref/transapp/logfile.html#2 @log file removal
-__APIREL__/ref/transapp/reclimit.html#2 Berkeley DB @recoverability
-__APIREL__/ref/transapp/recovery.html#2 recovery in @transaction protected applications
-__APIREL__/ref/transapp/throughput.html#2 @transaction throughput
-__APIREL__/ref/txn/config.html#2 @transaction configuration
-__APIREL__/ref/txn/intro.html#2 Berkeley DB and @transactions
-__APIREL__/ref/txn/limits.html#2 @transaction limits
-__APIREL__/ref/txn/nested.html#2 nested @transactions
-__APIREL__/ref/upgrade.2.0/intro.html#2 Upgrading to release @2.0
-__APIREL__/ref/upgrade.3.0/intro.html#2 Upgrading to release @3.0
-__APIREL__/ref/upgrade.3.1/intro.html#2 Upgrading to release @3.1
-__APIREL__/ref/upgrade.3.2/intro.html#2 Upgrading to release @3.2
-__APIREL__/ref/xa/config.html#2 configuring Berkeley DB with the @Tuxedo System
-__APIREL__/ref/xa/intro.html#2 @XA Resource Manager
-__APIREL__/utility/berkeley_db_svc.html#2 @berkeley_db_svc
-__APIREL__/utility/berkeley_db_svc.html#3 utility to support @RPC client/server
-__APIREL__/utility/db_archive.html#2 @db_archive
-__APIREL__/utility/db_archive.html#3 utility to @archive log files
-__APIREL__/utility/db_checkpoint.html#2 @db_checkpoint
-__APIREL__/utility/db_checkpoint.html#3 utility to take @checkpoints
-__APIREL__/utility/db_deadlock.html#2 @db_deadlock
-__APIREL__/utility/db_deadlock.html#3 utility to detect @deadlocks
-__APIREL__/utility/db_dump.html#2 @db_dump
-__APIREL__/utility/db_dump.html#3 utility to @dump databases as text files
-__APIREL__/utility/db_load.html#2 @db_load
-__APIREL__/utility/db_load.html#3 utility to @load text files into databases
-__APIREL__/utility/db_printlog.html#2 @db_printlog
-__APIREL__/utility/db_printlog.html#3 utility to display @log files as text
-__APIREL__/utility/db_recover.html#2 @db_recover
-__APIREL__/utility/db_recover.html#3 utility to @recover database environments
-__APIREL__/utility/db_stat.html#2 @db_stat
-__APIREL__/utility/db_stat.html#3 utility to display database and environment @statistics
-__APIREL__/utility/db_upgrade.html#2 @db_upgrade
-__APIREL__/utility/db_upgrade.html#3 utility to upgrade @database files
-__APIREL__/utility/db_upgrade.html#4 utility to @upgrade database files
-__APIREL__/utility/db_verify.html#2 @db_verify
-__APIREL__/utility/db_verify.html#3 utility to verify @database files
-__APIREL__/utility/db_verify.html#4 utility to @verify database files
diff --git a/bdb/docs/ref/program/appsignals.html b/bdb/docs/ref/program/appsignals.html
deleted file mode 100644
index 2b1d99bd6f3..00000000000
--- a/bdb/docs/ref/program/appsignals.html
+++ /dev/null
@@ -1,35 +0,0 @@
-
-
-
-
-
- When applications using Berkeley DB receive signals, it is important that they
-exit gracefully, discarding any Berkeley DB locks that they may hold. This is
-normally done by setting a flag when a signal arrives, and then checking
-for that flag periodically within the application. As Berkeley DB is not
-reentrant, the signal handler should not attempt to release locks and/or
-close the database handles itself. Reentering Berkeley DB is not guaranteed to
-work correctly and the results are undefined.
- If an application exits holding a lock, the situation is no different
-than if the application crashed, and all applications participating in
-the database environment must be shutdown, and then recovery must be
-performed. If this is not done, databases may be left in an
-inconsistent state or locks the application held may cause unresolvable
-deadlocks inside the environment, causing applications to hang.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/byteorder.html b/bdb/docs/ref/program/byteorder.html
deleted file mode 100644
index 6569ba88b27..00000000000
--- a/bdb/docs/ref/program/byteorder.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- The database files created by Berkeley DB can be created in either little or
-big-endian formats. By default, the native format of the machine on which
-the database is created will be used. Any format database can be used on
-a machine with a different native format, although it is possible that
-the application will incur a performance penalty for the run-time
-conversion.
- No user-specified data is converted in any way at all. Key or data items
-stored on machines of one format will be returned to the application
-exactly as stored on machines of another format.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/compatible.html b/bdb/docs/ref/program/compatible.html
deleted file mode 100644
index 72db97a5c36..00000000000
--- a/bdb/docs/ref/program/compatible.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-
-
-
- The Berkeley DB version 2 library provides backward compatible interfaces for
-the historic UNIX dbm, ndbm and hsearch
-interfaces. It also provides a backward compatible interface for the
-historic Berkeley DB 1.85 release.
- Berkeley DB version 2 does not provide database compatibility for any of the
-above interfaces, and existing databases must be converted manually. To
-convert existing databases from the Berkeley DB 1.85 format to the Berkeley DB version
-2 format, review the db_dump185 and db_load information.
-No utilities are provided to convert UNIX dbm, ndbm or
-hsearch databases.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/copy.html b/bdb/docs/ref/program/copy.html
deleted file mode 100644
index 80b6f942a78..00000000000
--- a/bdb/docs/ref/program/copy.html
+++ /dev/null
@@ -1,63 +0,0 @@
-
-
-
-
-
- Because file identification cookies (e.g., file names, device and inode
-numbers, volume and file IDs, etc.) are not necessarily unique or
-maintained across system reboots, each Berkeley DB database file contains a
-20-byte file identification bytestring that is stored in the first page
-of the database at a page byte offset of 36 bytes. When multiple
-processes or threads open the same database file in Berkeley DB, it is this
-bytestring that is used to ensure that the same underlying pages are
-updated in the shared memory buffer pool no matter which Berkeley DB handle is
-used for the operation.
- It is usually a bad idea to physically copy a database to a new name. In
-the few cases where copying is the best solution for your application,
-you must guarantee there are never two different databases with the same
-file identification bytestring in the memory pool at the same time.
-Copying databases is further complicated by the fact that the shared
-memory buffer pool does not discard all cached copies of pages for a
-database when the database is logically closed, that is, when
-DB->close is called. Nor is there a Berkeley DB interface to explicitly
-discard pages from the shared memory buffer pool for any particular
-database.
- Before copying a database, you must ensure that all modified pages have
-been written from the memory pool cache to the backing database file.
-This is done using the DB->sync or DB->close interfaces.
- Before using a copy of a database from Berkeley DB, you must ensure that all
-pages from any database with the same bytestring have been removed from
-the memory pool cache. If the environment in which you intend to open
-the copy of the database potentially has pages from files with identical
-bytestrings to the copied database (which is likely to be the case), there
-are a few possible solutions:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/dbsizes.html b/bdb/docs/ref/program/dbsizes.html
deleted file mode 100644
index 69b45868d71..00000000000
--- a/bdb/docs/ref/program/dbsizes.html
+++ /dev/null
@@ -1,45 +0,0 @@
-
-
-
-
-
- The largest database file that Berkeley DB can handle depends on the page size
-selected by the application. Berkeley DB stores database file page numbers as
-unsigned 32-bit numbers and database file page sizes as unsigned 16-bit
-numbers. Using the maximum database page size of 65536, this results in
-a maximum database file size of 248 (256 terabytes). The
-minimum database page size is 512 bytes, which results in a minimum
-maximum database size of 241 (2 terabytes).
- The largest database file Berkeley DB can support is potentially further limited
-if the host system does not have filesystem support for files larger than
-232, including the ability to seek to absolute offsets within
-those files.
- The largest key or data item that Berkeley DB can support is largely limited
-by available memory. Specifically, while key and data byte strings may
-be of essentially unlimited length, any one of them must fit into
-available memory so that it can be returned to the application. As some
-of the Berkeley DB interfaces return both key and data items to the application,
-those interfaces will require that any key/data pair fit simultaneously
-into memory. Further, as the access methods may need to compare key and
-data items with other key and data items, it may be a requirement that
-any two key or two data items fit into available memory. Finally, when
-writing applications supporting transactions, it may be necessary to have
-an additional copy of any data item in memory for logging purposes.
- The maximum Btree depth is 255.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/diskspace.html b/bdb/docs/ref/program/diskspace.html
deleted file mode 100644
index fb8425d8a26..00000000000
--- a/bdb/docs/ref/program/diskspace.html
+++ /dev/null
@@ -1,145 +0,0 @@
-
-
-
-
-
- It is possible to estimate the total database size based on the size of
-the data. Simply put, the following calculations attempt to figure out
-how many bytes you will need to hold a set of data and then how many pages
-it will take to actually store it on disk.
- Space freed by deleting key/data pairs from a Btree or Hash database is
-never returned to the filesystem, although it is reused where possible.
-This means that the Btree and Hash databases are grow-only. If enough
-keys are deleted from a database that shrinking the underlying file is
-desirable, you should create a new database and insert the records from
-the old one into it.
- These are rough estimates at best. For example, they do not take into
-account overflow records, filesystem metadata information, or real-life
-situations where the sizes of key and data items are wildly variable, and
-the page-fill factor changes over time.
- The formulas for the Btree access method are as follows:
-
-bytes-of-data = n-records *
- (bytes-per-entry + page-overhead-for-two-entries)
-
-n-pages-of-data = bytes-of-data / bytes-per-page
-
-total-pages-on-disk = n-pages-of-data * page-size
- The useful-bytes-per-page is a measure of the bytes on each page
-that will actually hold the application data. It is computed as the total
-number of bytes on the page that are available to hold application data,
-corrected by the percentage of the page that is likely to contain data.
-The reason for this correction is that the percentage of a page that
-contains application data can vary from close to 50% after a page split,
-to almost 100% if the entries in the database were inserted in sorted
-order. Obviously, the page-fill-factor can drastically alter
-the amount of disk space required to hold any particular data set. The
-page-fill factor of any existing database can be displayed using the
-db_stat utility.
- As an example, using an 8K page size, with an 85% page-fill factor, there
-are 6941 bytes of useful space on each page:
- The total bytes-of-data is an easy calculation: it is the number
-of key/data pairs plus the overhead required to store each pair on a page.
-The overhead to store a single item on a Btree page is 5 bytes. So,
-assuming 60,000,000 key/data pairs, each of which is 8 bytes long, there
-are 1440000000 bytes, or roughly 1.34GB, of total data:
- The total pages of data, n-pages-of-data, is the
-bytes-of-data divided by the useful-bytes-per-page. In
-the example, there are 224751 pages of data.
- The total bytes of disk space for the database is n-pages-of-data
-multiplied by the page-size. In the example, the result is
-1841160192 bytes, or roughly 1.71GB.
- The formulas for the Hash access method are as follows:
-
-bytes-of-data = n-records *
- (bytes-per-entry + page-overhead-for-two-entries)
-
-n-pages-of-data = bytes-of-data / bytes-per-page
-
-total-pages-on-disk = n-pages-of-data * page-size
- The useful-bytes-per-page is a measure of the bytes on each page
-that will actually hold the application data. It is computed as the total
-number of bytes on the page that are available to hold application data.
-If the application has explicitly set a page fill factor, then pages will
-not necessarily be kept full. For databases with a preset fill factor,
-see the calculation below. The page-overhead for Hash databases is 26
-bytes and the page-overhead-for-two-entries is 6 bytes.
- As an example, using an 8K page size, there are 8166 bytes of useful space
-on each page:
- The total bytes-of-data is an easy calculation: it is the number
-of key/data pairs plus the overhead required to store each pair on a page.
-In this case that's 6 bytes per pair. So, assuming 60,000,000 key/data
-pairs, each of which is 8 bytes long, there are 1320000000 bytes, or
-roughly 1.23GB, of total data:
- The total pages of data, n-pages-of-data, is the
-bytes-of-data divided by the useful-bytes-per-page. In
-this example, there are 161646 pages of data.
- The total bytes of disk space for the database is n-pages-of-data
-multiplied by the page-size. In the example, the result is
-1324204032 bytes, or roughly 1.23GB.
- Now, let's assume that the application specified a fill factor explicitly.
-The fill factor indicates the target number of items to place on a single
-page (a fill factor might reduce the utilization of each page, but it can
-be useful in avoiding splits and preventing buckets from becoming too
-large. Using our estimates above, each item is 22 bytes (16 + 6) and
-there are 8166 useful bytes on a page (8192 - 26). That means that, on
-average, you can fit 371 pairs per page.
- However, let's assume that the application designer knows that while most
-items are 8 bytes, they can sometimes be as large as 10 and it's very
-important to avoid overflowing buckets and splitting. Then, the
-application might specify a fill factor of 314.
- With a fill factor of 314, then the formula for computing database size
-is:
- or 191082.
- At 191082 pages, the total database size would be 1565343744 or 1.46GB.
- There are a few additional caveats with respect to Hash databases. This
-discussion assumes that the hash function does a good job of evenly
-distributing keys among hash buckets. If the function does not do this,
-you may find your table growing significantly larger than you expected.
-Secondly, in order to provide support for Hash databases co-existing with
-other databases in a single file, pages within a Hash database are
-allocated in power-of-2 chunks. That means that a Hash database with 65
-buckets will take up as much space as a Hash database with 128 buckets;
-each time the Hash database grows beyond its current power-of-two number
-of buckets, it allocates space for the next power-of-two buckets. This
-space may be sparsely allocated in the file system, but the files will
-appear to be their full size. Finally, because of this need for
-contiguous allocation, overflow pages and duplicate pages can be allocated
-only at specific points in the file, and this too can lead to sparse hash
-tables.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/environ.html b/bdb/docs/ref/program/environ.html
deleted file mode 100644
index 7f56109b5d7..00000000000
--- a/bdb/docs/ref/program/environ.html
+++ /dev/null
@@ -1,33 +0,0 @@
-
-
-
-
-
- The Berkeley DB library uses the following environment variables:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/errorret.html b/bdb/docs/ref/program/errorret.html
deleted file mode 100644
index fc6ad650d3e..00000000000
--- a/bdb/docs/ref/program/errorret.html
+++ /dev/null
@@ -1,108 +0,0 @@
-
-
-
-
-
- Except for the historic dbm, ndbm and hsearch
-interfaces, Berkeley DB does not use the global variable errno to
-return error values. The return values for all Berkeley DB functions are
-grouped into three categories:
-
-All values returned by Berkeley DB functions are less than 0 in order to avoid
-conflict with possible values of errno. Specifically, Berkeley DB
-reserves all values from -30,800 to -30,999 to itself as possible error
-values. There are a few Berkeley DB interfaces where it is possible for an
-application function to be called by a Berkeley DB function and subsequently
-fail with an application-specific return. Such failure returns will be
-passed back to the function that originally called a Berkeley DB interface.
-To avoid ambiguity as to the cause of the error, error values separate
-from the Berkeley DB error name space should be used.
- There are two special return values that are similar in meaning, and that
-are returned in similar situations, and therefore might be confused:
-DB_NOTFOUND and DB_KEYEMPTY.
- The DB_NOTFOUND error return indicates that the requested key/data
-pair did not exist in the database or that start- or end-of-file has been
-reached.
- The DB_KEYEMPTY error return indicates that the requested key/data
-pair logically exists but was never explicitly created by the application
-(the Recno and Queue access methods will automatically create key/data
-pairs under some circumstances; see DB->open for more
-information), or that the requested key/data pair was deleted and never
-re-created. In addition, the Queue access method will return
-DB_KEYEMPTY for records which were created as part of a
-transaction which was later aborted, and never re-created.
- When multiple threads of control are modifying the database, there is
-normally the potential for deadlock. In Berkeley DB, deadlock is signified by
-an error return from the Berkeley DB function of the value
-DB_LOCK_DEADLOCK. Whenever a Berkeley DB function returns
-DB_LOCK_DEADLOCK, the enclosing transaction should be aborted.
- Any Berkeley DB function that attempts to acquire locks can potentially return
-DB_LOCK_DEADLOCK. Practically speaking, the safest way to deal
-with applications that can deadlock is to handle an
-DB_LOCK_DEADLOCK return from any Berkeley DB access method call.
- When multiple threads of control are modifying the database, there is
-normally the potential for deadlock. In order to avoid deadlock,
-applications may specify, on a per-transaction basis, that if a lock is
-unavailable, the Berkeley DB operation should return immediately instead of
-waiting on the lock. The error return in this case will be
-DB_LOCK_NOTGRANTED. Whenever a Berkeley DB function returns
-DB_LOCK_NOTGRANTED, the enclosing transaction should be aborted.
- 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 corrupted
-database, or a log write failure because the disk is out of free space.
-The only way to recover from these failures is to have all threads of
-control exit the Berkeley DB environment, run recovery of the environment, and
-re-enter Berkeley DB. (It is not strictly necessary that the processes exit,
-although that is the only way to recover system resources, such as file
-descriptors and memory, allocated by Berkeley DB.)
- When this type of error is encountered, the error value
-DB_RUNRECOVERY is returned. This error can be returned by any
-Berkeley DB interface. Once DB_RUNRECOVERY is returned by any
-interface, it will be returned from all subsequent Berkeley DB calls made by
-any threads or processes participating in the environment.
- Optionally, applications may also specify a fatal-error callback function
-using the DBENV->set_paniccall function. This callback function will be
-called with two arguments: a reference to the DB_ENV structure associated
-with the environment, and the errno value associated with the
-underlying error that caused the problem.
- Applications can handle such fatal errors in one of two ways: by checking
-for DB_RUNRECOVERY as part of their normal Berkeley DB error return
-checking, similarly to DB_LOCK_DEADLOCK or any other error, or,
-in applications that have no cleanup processing of their own, by simply
-exiting the application when the callback function is called.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/extending.html b/bdb/docs/ref/program/extending.html
deleted file mode 100644
index 6f276d8dca5..00000000000
--- a/bdb/docs/ref/program/extending.html
+++ /dev/null
@@ -1,242 +0,0 @@
-
-
-
-
-
- Berkeley DB includes tools to assist in the development of application-specific
-logging and recovery. Specifically, given a description of the
-information to be logged, these tools will automatically create logging
-functions (functions that take the values as parameters and construct a
-single record that is written to the log), read functions (functions that
-read a log record and unmarshall the values into a structure that maps
-onto the values you chose to log), a print function (for debugging),
-templates for the recovery functions, and automatic dispatching to your
-recovery functions.
- Log records are described in files named XXX.src, where "XXX" is a
-unique prefix. The prefixes currently used in the Berkeley DB package are
-btree, crdel, db, hash, log, qam, and txn. These files contain interface
-definition language descriptions for each type of log record that
-is supported.
- All lines beginning with a hash character in .src files are
-treated as comments.
- The first non-comment line in the file should begin with the keyword
-PREFIX followed by a string that will be prepended to every function.
-Frequently, the PREFIX is either identical or similar to the name of the
-.src file.
- The rest of the file consists of one or more log record descriptions.
-Each log record description begins with the line:
- and ends with the line:
- The RECORD_NAME keyword should be replaced with a unique record name for
-this log record. Record names must only be unique within .src
-files.
- The RECORD_NUMBER keyword should be replaced with a record number. Record
-numbers must be unique for an entire application, that is, both
-application-specific and Berkeley DB log records must have unique values.
-Further, as record numbers are stored in log files, which often must be
-portable across application releases, no record number should ever be
-re-used. The record number space below 10,000 is reserved for Berkeley DB
-itself, applications should choose record number values equal to or
-greater than 10,000.
- Between the BEGIN and END statements, there should be one line for each
-data item that will be logged in this log record. The format of these
-lines is as follows:
- The keyword ARG indicates that the argument is a simple parameter of the
-type specified. The keyword DBT indicates that the argument is a DBT
-containing a length and pointer. The keyword PTR indicates that the
-argument is a pointer to the data type specified and that the entire type
-should be logged.
- The variable name is the field name within the structure that will be used
-to reference this item. The variable type is the C type of the variable,
-and the printf format should be "s", for string, "d" for signed integral
-type, or "u" for unsigned integral type.
- For each log record description found in the file, the following structure
-declarations and #defines will be created in the file PREFIX_auto.h.
-
-#define DB_PREFIX_RECORD_TYPE /* Integer ID number */
-
-typedef struct _PREFIX_RECORD_TYPE_args {
- /*
- * These three fields are generated for every record.
- */
- u_int32_t type; /* Record type used for dispatch. */
-
- /*
- * Transaction id that identifies the transaction on whose
- * behalf the record is being logged.
- */
- DB_TXN *txnid;
-
- /*
- * The LSN returned by the previous call to log for
- * this transaction.
- */
- DB_LSN *prev_lsn;
-
- /*
- * The rest of the structure contains one field for each of
- * the entries in the record statement.
- */
-}; The DB_PREFIX_RECORD_TYPE will be described in terms of a value
-DB_PREFIX_BEGIN, which should be specified by the application writer in
-terms of the library provided DB_user_BEGIN macro (this is the value of
-the first identifier available to users outside the access method system).
- In addition to the PREFIX_auto.h file, a file named PREFIX_auto.c is
-created, containing the following functions for each record type:
- The log function marshalls the parameters into a buffer and calls
-log_put on that buffer returning 0 on success and 1 on failure.
- The read function takes a buffer and unmarshalls its contents into a
-structure of the appropriate type. It returns 0 on success and non-zero
-on error. After the fields of the structure have been used, the pointer
-returned from the read function should be freed.
- The recovery function is called on each record read from the log during
-system recovery or transaction abort.
- The recovery function is created in the file PREFIX_rtemp.c since it
-contains templates for recovery functions. The actual recovery functions
-must be written manually, but the templates usually provide a good starting
-point.
- The recovery initialization function registers each log record type
-declared with the recovery system, so that the appropriate function is
-called during recovery.
- Applications use the automatically generated functions as follows:
- The recovery functions (described below) can be called in two cases:
- For each log record type you declare, you must write the appropriate
-function to undo and redo the modifications. The shell of these functions
-will be generated for you automatically, but you must fill in the details.
- Your code should be able to detect whether the described modifications
-have been applied to the data or not. The function will be called with
-the "op" parameter set to DB_TXN_ABORT when a transaction that wrote the
-log record aborts and with DB_TXN_FORWARD_ROLL and DB_TXN_BACKWARD_ROLL
-during recovery. The actions for DB_TXN_ABORT and DB_TXN_BACKWARD_ROLL
-should generally be the same. For example, in the access methods, each
-page contains the log sequence number of the most recent log record that
-describes a modification to the page. When the access method changes a
-page it writes a log record describing the change and including the the
-LSN that was on the page before the change. This LSN is referred to as
-the previous LSN. The recovery functions read the page described by a
-log record and compare the log sequence number (LSN) on the page to the
-LSN they were passed. If the page LSN is less than the passed LSN and
-the operation is undo, no action is necessary (because the modifications
-have not been written to the page). If the page LSN is the same as the
-previous LSN and the operation is redo, then the actions described are
-reapplied to the page. If the page LSN is equal to the passed LSN and
-the operation is undo, the actions are removed from the page; if the page
-LSN is greater than the passed LSN and the operation is redo, no further
-action is necessary. If the action is a redo and the LSN on the page is
-less than the previous LSN in the log record this is an error, since this
-could only happen if some previous log record was not processed.
- Please refer to the internal recovery functions in the Berkeley DB library
-(found in files named XXX_rec.c) for examples of how recovery functions
-should work.
- If your application cannot conform to the default logging and recovery
-structure, then you will have to create your own logging and recovery
-functions explicitly.
- First, you must decide how you will dispatch your records. Encapsulate
-this algorithm in a dispatch function that is passed to DBENV->open.
-The arguments for the dispatch function are as follows:
- When you abort a transaction, txn_abort will read the last log
-record written for the aborting transaction and will then call your
-dispatch function. It will continue looping, calling the dispatch
-function on the record whose LSN appears in the lsn parameter of the
-dispatch call (until a NULL LSN is placed in that field). The dispatch
-function will be called with the op set to DB_TXN_ABORT.
- Your dispatch function can do any processing necessary. See the code
-in db/db_dispatch.c for an example dispatch function (that is based on
-the assumption that the transaction ID, previous LSN, and record type
-appear in every log record written).
- If you do not use the default recovery system, you will need to construct
-your own recovery process based on the recovery program provided in
-db_recover/db_recover.c. Note that your recovery functions will need to
-correctly process the log records produced by calls to txn_begin
-and txn_commit.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/mt.html b/bdb/docs/ref/program/mt.html
deleted file mode 100644
index 31110920aa9..00000000000
--- a/bdb/docs/ref/program/mt.html
+++ /dev/null
@@ -1,95 +0,0 @@
-
-
-
-
-
- The Berkeley DB library is not itself multi-threaded. The library was
-deliberately architected to not use threads internally because of the
-portability problems that using threads within the library would
-introduce.
- Berkeley DB supports multi-threaded applications with the caveat that it loads
-and calls functions that are commonly available in C language environments.
-Other than this usage, Berkeley DB has no static data and maintains no local
-context between calls to Berkeley DB functions.
- Environment and database object handles returned from Berkeley DB library
-functions are free-threaded. No other object handles returned from
-the Berkeley DB library are free-threaded.
- The following rules should be observed when using threads to
-access the Berkeley DB library:
- Threading is assumed in the Java API, so no special flags are required,
-and Berkeley DB functions will always behave as if the DB_THREAD flag
-was specified.
- Only a single thread may call the DBENV->close or DB->close functions
-for a returned environment or database handle.
- No other Berkeley DB handles are free-threaded, for example, cursors and
-transactions may not span threads as their returned handles are not
-free-threaded.
- For this reason, if the DB_THREAD handle was specified to the
-DB->open function, either DB_DBT_MALLOC, DB_DBT_REALLOC
-or DB_DBT_USERMEM must be specified in the DBT when
-performing any non-cursor key or data retrieval.
- Cursors may not span transactions or threads. Each cursor must be
-allocated and de-allocated within the same transaction and within
-the same thread.
- If blocking mutexes are available, for example POSIX pthreads, they will
-be used. Otherwise, the Berkeley DB library will make a system call to pause
-for some amount of time when it is necessary to wait on a lock. This may
-not be optimal, especially in a thread-only environment where it will be
-more efficient to explicitly yield the processor to another thread.
- It is possible to specify a yield function on an per-application basis.
-See db_env_set_func_yield for more information.
- It is possible to specify the number of attempts that will be made to
-acquire the mutex before waiting. Se db_env_set_tas_spins for
-more information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/namespace.html b/bdb/docs/ref/program/namespace.html
deleted file mode 100644
index 519f5f61c74..00000000000
--- a/bdb/docs/ref/program/namespace.html
+++ /dev/null
@@ -1,44 +0,0 @@
-
-
-
-
-
- The Berkeley DB library is careful to avoid C language programmer name spaces,
-but there are a few potential areas for concern, mostly in the Berkeley DB
-include file db.h. The db.h include file defines a number of types and
-strings. Where possible, all of these types and strings are prefixed with
-"DB_" or "db_". There are a few notable exceptions.
- The Berkeley DB library uses a macro named "__P" to configure for systems that
-do not provide ANSI C function prototypes. This could potentially collide
-with other systems using a "__P" macro for similar or different purposes.
- The Berkeley DB library needs information about specifically sized types for
-each architecture. If they are not provided by the system, they are
-typedef'd in the db.h include file. The types which may be typedef'd
-by db.h include the following: u_int8_t, int16_t, u_int16_t, int32_t,
-u_int32_t, u_char, u_short, u_int and u_long.
- The Berkeley DB library declares a number of external routines. All of these
-routines are prefixed with the strings "db_", "lock_", "log_", "memp_"
-or "txn_". All internal routines are prefixed with the strings "__db_",
-"__lock_," "__log_", "__memp_" or "__txn_".
- Berkeley DB environments create or use some number of files in environment home
-directories. These files are named DB_CONFIG, "log.NNNNNNNNNN"
-(e.g., log.0000000003), or with the string prefix "__db" (e.g., __db.001).
-Database files that match these names should not be created in the
-environment directory.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/recimp.html b/bdb/docs/ref/program/recimp.html
deleted file mode 100644
index 240eccd8bc9..00000000000
--- a/bdb/docs/ref/program/recimp.html
+++ /dev/null
@@ -1,49 +0,0 @@
-
-
-
-
-
- The physical recovery process works as follows:
- First, find the last checkpoint that completed. Since the system may
-have crashed while writing a checkpoint, this implies finding the
-second-to-last checkpoint in the log files. Read forward from this
-checkpoint, opening any database files for which modifications are found
-in the log.
- Then, read backward from the end of the log. For each commit record
-encountered, record its transaction ID. For every other data update
-record, find the transaction ID of the record. If that transaction ID
-appears in the list of committed transactions, do nothing; if it does not
-appear in the committed list, then call the appropriate recovery routine
-to undo the operation.
- In the case of catastrophic recovery, this roll-backward pass continues
-through all the present log files. In the case of normal recovery, this
-pass continues until we find a checkpoint written before the second-to-last
-checkpoint described above.
- When the roll-backward pass is complete, the roll-forward pass begins at
-the point where the roll-backward pass ended. Each record is read and if
-its transaction id is in the committed list, then the appropriate recovery
-routine is called to redo the operation if necessary.
- In a distributed transaction environment, there may be transactions that
-are prepared, but not yet committed. If these transactions are XA
-transactions, then they are rolled forward to their current state, and an
-active transaction corresponding to it is entered in the transaction table
-so that the XA transaction manager may call either transaction abort or
-commit, depending on the outcome of the overall transaction. If the
-transaction is not an XA transaction, then it is aborted like any other
-transactions would be.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/runtime.html b/bdb/docs/ref/program/runtime.html
deleted file mode 100644
index a6f860bcac0..00000000000
--- a/bdb/docs/ref/program/runtime.html
+++ /dev/null
@@ -1,57 +0,0 @@
-
-
-
-
-
- There are a few interfaces that support run-time configuration of Berkeley DB.
-First is a group of interfaces that allow applications to intercept
-Berkeley DB requests for underlying library or system call functionality:
- These interfaces are only available from the Berkeley DB C language API.
- In addition, there are a few interfaces that allow applications to
-re-configure, on an application-wide basis, Berkeley DB behaviors.
- These interfaces are available from all of the Berkeley DB programmatic APIs.
- A not-uncommon problem for applications is the new API in Solaris 2.6
-for manipulating large files. As this API was not part of Solaris 2.5,
-it is difficult to create a single binary that takes advantage of the
-large file functionality in Solaris 2.6 but which still runs on Solaris
-2.5. Example code that supports this is
-included in the Berkeley DB distribution.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/scope.html b/bdb/docs/ref/program/scope.html
deleted file mode 100644
index 19814793259..00000000000
--- a/bdb/docs/ref/program/scope.html
+++ /dev/null
@@ -1,71 +0,0 @@
-
-
-
-
-
- The Berkeley DB library has a number of object handles. The following table
-lists those handles, their scope, and if they are free-threaded, that
-is, if multiple threads within a process can share them.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/program/solaris.txt b/bdb/docs/ref/program/solaris.txt
deleted file mode 100644
index d2ec3168242..00000000000
--- a/bdb/docs/ref/program/solaris.txt
+++ /dev/null
@@ -1,213 +0,0 @@
-#ifdef OS_solaris
- * This is all for Solaris 2.6.
- *
- * Sun defined a new API in Solaris2.6 to be used when manipulating large
- * (>2Gbyte) files. This API isn't present in 2.5.x, so we can't simply
- * call it -- that would mean two binaries, one for 2.5.x and the other for
- * 2.6. Not pretty. So, what we do here is determine the OS on which we're
- * running at runtime, and adjust the underlying Berkeley DB calls to use
- * the new API if it's there.
- */
-
-/* This must match the definition of stat64 in Solaris2.6 */
-struct our_stat64 {
- dev_t st_dev;
- long st_pad1[3]; /* reserve for dev expansion */
- u_longlong_t st_ino;
- mode_t st_mode;
- nlink_t st_nlink;
- uid_t st_uid;
- gid_t st_gid;
- dev_t st_rdev;
- long st_pad2[2];
- longlong_t st_size;
- timestruc_t mst_atime;
- timestruc_t mst_mtime;
- timestruc_t mst_ctime;
- long st_blksize;
- longlong_t st_blocks; /* large file support */
- char st_fstype[_ST_FSTYPSZ];
- long st_pad4[8]; /* expansion area */
-};
-
-#define MEGABYTE (1024 * 1024)
-
-typedef int (*open_fn)(const char *path, int flags, ...);
-typedef longlong_t (*lseek64_fn)(int fildes, longlong_t offset, int whence);
-typedef longlong_t (*fstat64_fn)(int fildes, struct our_stat64 *s);
-typedef void* (*mmap64_fn)(void* addr, size_t len, int prot, int flags,
-int filedes, longlong_t off);
-
-static fstat64_fn os_fstat64_fn = NULL;
-static lseek64_fn os_lseek64_fn = NULL;
-static mmap64_fn os_mmap64_fn = NULL;
-static open_fn os_open64_fn = NULL;
-
-static int dblayer_load_largefile_fns()
-{
- void *lib_handle = NULL;
- void *function_found = NULL;
- int ret = 0;
-
- lib_handle = dlopen(NULL, RTLD_NOW);
- if (NULL == lib_handle)
- return (-1);
-
- function_found = dlsym(lib_handle,"open64");
- if (NULL == function_found)
- return (-1);
- os_open64_fn = (open_fn)function_found;
-
- function_found = dlsym(lib_handle,"lseek64");
- if (NULL == function_found)
- return (-1);
- os_lseek64_fn = (lseek64_fn)function_found;
-
- function_found = dlsym(lib_handle,"fstat64");
- if (NULL == function_found)
- return (-1);
- os_fstat64_fn = (fstat64_fn)function_found;
-
- function_found = dlsym(lib_handle,"mmap64");
- if (NULL == function_found)
- return (-1);
- os_mmap64_fn = (mmap64_fn)function_found;
-
- return 0;
-}
-
-/* Helper function for large seeks */
-static int dblayer_seek_fn_solaris(int fd,
- size_t pgsize, db_pgno_t pageno, u_long relative, int whence)
-{
- longlong_t offset = 0;
- longlong_t ret = 0;
-
- if (NULL == os_lseek64_fn) {
- return -1;
- }
-
- offset = (longlong_t)pgsize * pageno + relative;
-
- ret = (*os_lseek64_fn)(fd,offset,whence);
-
- return (ret == -1) ? errno : 0;
-}
-
-/* Helper function for large file mmap */
-static int dblayer_map_solaris(fd, len, is_private, is_rdonly, addr)
- int fd, is_private, is_rdonly;
- size_t len;
- void **addr;
-{
- void *p;
- int flags, prot;
-
- flags = is_private ? MAP_PRIVATE : MAP_SHARED;
- prot = PROT_READ | (is_rdonly ? 0 : PROT_WRITE);
-
- if ((p = (*os_mmap64_fn)(NULL,
- len, prot, flags, fd, (longlong_t)0)) == (void *)MAP_FAILED)
- return (errno);
-
- *addr = p;
- return (0);
-}
-
-/* Helper function for large fstat */
-static int dblayer_ioinfo_solaris(const char *path,
- int fd, u_int32_t *mbytesp, u_int32_t *bytesp, u_int32_t *iosizep)
-{
- struct our_stat64 sb;
-
- if (NULL == os_fstat64_fn) {
- return -1;
- }
-
- if ((*os_fstat64_fn)(fd, &sb) == -1)
- return (errno);
-
- /* Return the size of the file. */
- if (mbytesp != NULL)
- *mbytesp = (u_int32_t) (sb.st_size / (longlong_t)MEGABYTE);
- if (bytesp != NULL)
- *bytesp = (u_int32_t) (sb.st_size % (longlong_t)MEGABYTE);
-
- /*
- * Return the underlying filesystem blocksize, if available. Default
- * to 8K on the grounds that most OS's use less than 8K as their VM
- * page size.
- */
- if (iosizep != NULL)
- *iosizep = sb.st_blksize;
- return (0);
-}
-#endif
-
-#ifdef irix
- * A similar mess to Solaris: a new API added in IRIX6.2 to support large
- * files. We always build on 6.2 or later, so no need to do the same song
- * and dance as on Solaris -- we always have the header files for the
- * 64-bit API.
- */
-
-/* Helper function for large seeks */
-static int dblayer_seek_fn_irix(int fd,
- size_t pgsize, db_pgno_t pageno, u_long relative, int whence)
-{
- off64_t offset = 0;
- off64_t ret = 0;
-
- offset = (off64_t)pgsize * pageno + relative;
-
- ret = lseek64(fd,offset,whence);
-
- return (ret == -1) ? errno : 0;
-}
-
-/* Helper function for large fstat */
-static int dblayer_ioinfo_irix(const char *path,
- int fd, u_int32_t *mbytesp, u_int32_t *bytesp, u_int32_t *iosizep)
-{
- struct stat64 sb;
-
- if (fstat64(fd, &sb) == -1) {
- return (errno);
- }
-
- /* Return the size of the file. */
- if (mbytesp != NULL)
- *mbytesp = (u_int32_t) (sb.st_size / (off64_t)MEGABYTE);
- if (bytesp != NULL)
- *bytesp = (u_int32_t) (sb.st_size % (off64_t)MEGABYTE);
-
- if (iosizep != NULL)
- *iosizep = sb.st_blksize;
- return (0);
-}
-#endif /* irix */
-
-static int dblayer_override_libdb_functions(dblayer_private *priv)
-{
-#if defined(OS_solaris)
- int ret = 0;
-
- ret = dblayer_load_largefile_fns();
- if (0 != ret) {
- Debug("Not Solaris2.6: no large file support enabled\n");
- } else {
- /* Means we did get the XXX64 functions, so let's use them */
- db_jump_set((void*)os_open64_fn, DB_FUNC_OPEN);
- db_jump_set((void*)dblayer_seek_fn_solaris, DB_FUNC_SEEK);
- db_jump_set((void*)dblayer_ioinfo_solaris, DB_FUNC_IOINFO);
- db_jump_set((void*)dblayer_map_solaris, DB_FUNC_MAP);
- Debug("Solaris2.6: selected 64-bit file handling.\n");
- }
-#else
-#if defined (irix)
- db_jump_set((void*)dblayer_seek_fn_irix, DB_FUNC_SEEK);
- db_jump_set((void*)dblayer_ioinfo_irix, DB_FUNC_IOINFO);
-#endif /* irix */
-#endif /* OS_solaris */
- return 0;
-}
diff --git a/bdb/docs/ref/program/version.html b/bdb/docs/ref/program/version.html
deleted file mode 100644
index d1b1254a178..00000000000
--- a/bdb/docs/ref/program/version.html
+++ /dev/null
@@ -1,45 +0,0 @@
-
-
-
-
-
- Each release of the Berkeley DB library has a major version number, a minor
-version number, and a patch number.
- The major version number changes only when major portions of the Berkeley DB
-functionality have been changed. In this case, it may be necessary to
-significantly modify applications in order to upgrade them to use the new
-version of the library.
- The minor version number changes when Berkeley DB interfaces have changed, and
-the new release is not entirely backward compatible with previous releases.
-To upgrade applications to the new version, they must be recompiled, and
-potentially, minor modifications made, (e.g., the order of arguments to a
-function might have changed).
- The patch number changes on each release. If only the patch number
-has changed in a release, applications do not need to be recompiled,
-and they can be upgraded to the new version by simply installing a
-new version of the shared library.
- Internal Berkeley DB interfaces may change at any time and during any release,
-without warning. This means that the library must be entirely recompiled
-and reinstalled when upgrading to new releases of the library, as there
-is no guarantee that modules from the current version of the library will
-interact correctly with modules from a previous release.
- To retrieve the Berkeley DB version information, applications should use the
-db_version interface. In addition to the above information, the
-db_version interface returns a string encapsulating the version
-information, suitable for display to a user.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/refs/bdb_usenix.html b/bdb/docs/ref/refs/bdb_usenix.html
deleted file mode 100644
index 58e82b57314..00000000000
--- a/bdb/docs/ref/refs/bdb_usenix.html
+++ /dev/null
@@ -1,1120 +0,0 @@
-
-
-
-
-Michael A. Olson
-
-Berkeley DB is an Open Source embedded database system with a number
-of key advantages over comparable systems. It is simple to use, supports
-concurrent access by multiple users, and provides industrial-strength
-transaction support, including surviving system and disk crashes. This
-paper describes the design and technical features of Berkeley DB, the
-distribution, and its license.
-
-The Berkeley Database (Berkeley DB) is an embedded database system
-that can be used in applications requiring high-performance
-concurrent storage and retrieval of key/value pairs. The software
-is distributed as a library that can be linked directly into an
-application.
-It provides a variety of programmatic interfaces,
-including callable APIs for C, C++, Perl, Tcl and Java.
-Users may download Berkeley DB from Sleepycat Software's Web site,
-at
-www.sleepycat.com.
-
-Sleepycat distributes Berkeley DB as an Open Source product. The company
-collects license fees for certain uses of the software and sells support
-and services.
-
-Berkeley DB began as a new implementation of a hash access method
-to replace both
-hsearch
-and the various
-dbm
-implementations
-(dbm from AT&T,
-ndbm
-from Berkeley, and
-gdbm
-from the GNU project).
-In 1990 Seltzer and Yigit produced a package called Hash to do this
-[Selt91].
-
-The first general release of Berkeley DB, in 1991,
-included some interface changes and a new B+tree access method.
-At roughly the same time, Seltzer and Olson
-developed a prototype transaction
-system based on Berkeley DB, called LIBTP [Selt92],
-but never released the code.
-
-The 4.4BSD UNIX release included Berkeley DB 1.85 in 1992.
-Seltzer and Bostic maintained the code in the early 1990s
-in Berkeley and in Massachusetts.
-Many users adopted the code during this period.
-
-By mid-1996,
-users wanted commercial support for the software.
-In response, Bostic and Seltzer formed Sleepycat Software.
-The company enhances, distributes, and
-supports Berkeley DB and supporting software and documentation.
-Sleepycat released version 2.1 of Berkeley DB in mid-1997
-with important new features, including
-support for concurrent access to databases.
-The company makes about three commercial releases a year,
-and most recently shipped version 2.8.
-
-The C interfaces in Berkeley DB permit
-dbm-style
-record management
-for databases,
-with significant extensions to handle duplicate data items elegantly,
-to deal with concurrent access, and to provide transactional
-support so that multiple changes can be simultaneously committed
-(so that they are made permanent) or rolled back (so that the
-database is restored to its state at the beginning of the transaction).
-
-C++ and Java interfaces provide a small set of classes for
-operating on a database. The main class in both cases is called
-Db,
-and provides methods that encapsulate the
-dbm-style
-interfaces that the C interfaces provide.
-
-Tcl and Perl interfaces allow developers working in those languages
-to use Berkeley DB in their applications.
-Bindings for both languages are included in the distribution.
-
-Developers may compile their applications and link in Berkeley DB
-statically or dynamically.
-
-The Berkeley DB library supports concurrent access to databases.
-It can be linked
-into standalone applications, into a collection of cooperating applications,
-or into servers that handle requests and do database operations on
-behalf of clients.
-
-Compared to using a standalone database management system, Berkeley
-DB is easy to understand and simple to use. The
-software stores and retrieves records, which consist of key/value pairs.
-Keys are used to locate items and can be any data type or structure
-supported by the programming language.
-
-The programmer can provide the functions that Berkeley DB uses to
-operate on keys.
-For example,
-B+trees can use a custom comparison function,
-and the Hash access method can use a custom hash function.
-Berkeley DB uses default functions if none are supplied.
-Otherwise, Berkeley DB does not examine or interpret either keys
-or values in any way.
-Values may be arbitrarily long.
-
-It is also important to understand what Berkeley DB is not.
-It is not a database server that handles network requests. It is not an
-SQL engine that executes queries. It is not a relational or object-oriented
-database management system.
-
-It is possible to build any of those on top of Berkeley DB,
-but the package, as distributed,
-is an embedded database engine. It has been designed
-to be portable, small, fast, and reliable.
-
-Berkeley DB is embedded in a variety of proprietary and Open Source
-software packages.
-This section highlights a few of the products that use it.
-
-Directory servers, which do data storage and retrieval using the
-Local Directory Access Protocol (LDAP), provide naming and directory
-lookup service on local-area networks.
-This service is,
-essentially,
-database query and update,
-but uses a simple protocol rather than SQL or ODBC.
-Berkeley DB is the embedded data manager in the majority of deployed
-directory servers today,
-including LDAP servers from Netscape,
-MessageDirect (formerly Isode),
-and others.
-
-Berkeley DB is also embedded in a large number of mail servers.
-Intermail,
-from Software.com,
-uses Berkeley DB as a message store
-and as the backing store for its directory server.
-The sendmail server
-(including both the commercial Sendmail Pro offering from Sendmail,
-Inc. and the version distributed by sendmail.org)
-uses Berkeley DB to store aliases and other information.
-Similarly,
-Postfix (formerly VMailer) uses Berkeley DB
-to store administrative information.
-
-In addition,
-Berkeley DB is embedded in a wide variety of other software products.
-Example applications include managing access control lists,
-storing user keys in a public-key infrastructure,
-recording machine-to-network-address mappings in address servers,
-and storing configuration and device information in video
-post-production software.
-
-Finally,
-Berkeley DB is a part of many other Open Source software packages
-available on the Internet.
-For example,
-the software is embedded in the Apache Web server and the Gnome desktop.
-
-In database terminology, an access method is the disk-based structure
-used to store data and the operations available on that structure.
-For example, many database systems support a B+tree access method.
-B+trees allow equality-based lookups (find keys equal to some constant),
-range-based lookups (find keys between two constants) and record
-insertion and deletion.
-
-Berkeley DB supports three access methods: B+tree,
-Extended Linear Hashing (Hash),
-and Fixed- or Variable-length Records (Recno).
-All three operate on records composed of a key and a data value.
-In the B+tree and Hash access methods, keys can have arbitrary structure.
-In the Recno access method, each record is assigned a record number, which
-serves as the key.
-In all the access methods, the
-value can have arbitrary structure.
-The programmer can supply comparison or hashing functions for keys,
-and Berkeley DB stores and retrieves values without
-interpreting them.
-
-All of the access methods use the host filesystem as a backing store.
-
-Berkeley DB includes a Hash access method that implements extended
-linear hashing [Litw80].
-Extended linear hashing adjusts the hash function as the hash
-table grows, attempting to keep all buckets underfull in the steady
-state.
-
-The Hash access method supports insertion and deletion of records and
-lookup by exact match only. Applications may iterate over all records
-stored in a table, but the order in which they are returned is undefined.
-
-Berkeley DB includes a B+tree [Come79] access method.
-B+trees store records of key/value pairs in leaf pages,
-and pairs of (key, child page address) at internal nodes.
-Keys in the tree are stored in sorted order,
-where the order is determined by the comparison function supplied when the
-database was created.
-Pages at the leaf level of the tree include pointers
-to their neighbors to simplify traversal. B+trees support lookup by
-exact match (equality) or range (greater than or equal to a key).
-Like Hash tables, B+trees support record insertion,
-deletion, and iteration over all records in the tree.
-
-As records are inserted and pages in the B+tree fill up, they are split,
-with about half the keys going into a new peer page at the same level in
-the tree.
-Most B+tree implementations leave both nodes half-full after a split.
-This leads to poor performance in a common case, where the caller inserts
-keys in order.
-To handle this case, Berkeley DB keeps track of the insertion order,
-and splits pages unevenly to keep pages fuller.
-This reduces tree size, yielding better search performance and smaller
-databases.
-
-On deletion, empty pages are coalesced by reverse splits
-into single pages.
-The access method does no other page balancing on insertion
-or deletion.
-Keys are not moved among pages at every update
-to keep the tree well-balanced. While this could improve search times
-in some cases, the additional code complexity leads to slower updates and
-is prone to deadlocks.
-
-For simplicity, Berkeley DB B+trees do no prefix compression of keys
-at internal or leaf nodes.
-
-Berkeley DB includes a fixed- or variable-length record access method,
-called
-Recno.
-The Recno access method assigns logical record numbers to each
-record,
-and can search for and update records by record number.
-Recno is able,
-for example,
-to load a text file into a database,
-treating each line as a record.
-This permits fast searches by line number for applications like
-text editors [Ston82].
-
-Recno is actually built
-on top of the B+tree access method and provides a simple interface
-for storing sequentially-ordered data values.
-The Recno access method generates keys internally.
-The programmer's view of the values is that
-they are numbered sequentially from one.
-Developers can choose to have records automatically renumbered
-when lower-numbered records are added or deleted.
-In this case, new keys can be inserted between existing keys.
-
-This section describes important features of Berkeley DB.
-In general,
-developers can choose which features are useful to them,
-and use only those that are required by their application.
-
-For example,
-when an application opens a database, it can declare the degree of
-concurrency and recovery that it requires. Simple stand-alone applications,
-and in particular ports of applications that used
-dbm
-or one of its
-variants, generally do not require concurrent access or crash recovery.
-Other applications, such as enterprise-class database management systems
-that store sales transactions or other critical data, need full
-transactional service. Single-user operation is faster than multi-user
-operation, since no overhead is incurred by locking. Running with
-the recovery system disabled is faster than running with it enabled,
-since log records need not be written when changes are made to the
-database.
-
-In addition, some core subsystems, including the locking system and
-the logging facility,
-can be used outside the context of the access methods as well.
-Although few users have chosen to do so, it is possible to
-use only the lock manager in Berkeley DB to control concurrency
-in an application, without using any of the standard database services.
-Alternatively, the caller can integrate locking of non-database resources
-with Berkeley DB's transactional two-phase locking system, to impose
-transaction semantics on objects outside the database.
-
-Berkeley DB defines a simple API for database management.
-The package does not include industry-standard
-programmatic interfaces such as Open Database Connectivity (ODBC),
-Object Linking and Embedding for Databases (OleDB), or Structured
-Query Language (SQL). These interfaces, while useful, were
-designed to promote interoperability of database systems, and not
-simplicity or performance.
-
-In response to customer demand,
-Berkeley DB 2.5 introduced support for the XA standard [Open94].
-XA permits Berkeley DB to participate in distributed transactions
-under a transaction processing monitor like Tuxedo from BEA Systems.
-Like XA, other standard interfaces can be built on top of the
-core system.
-The standards do not belong inside Berkeley DB,
-since not all applications need them.
-
-A database user may need to search for particular keys in a database,
-or may simply want to browse available records.
-Berkeley DB supports both keyed access,
-to find one or more records with a given key,
-or sequential access,
-to retrieve all the records in the database one at a time.
-The order of the records returned during sequential scans
-depends on the access method.
-B+tree and Recno databases return records in sort order,
-and Hash databases return them in apparently random order.
-
-Similarly,
-Berkeley DB defines simple interfaces for inserting,
-updating,
-and deleting records in a database.
-
-Berkeley DB manages keys and values as large as
-232 bytes.
-Since the time required to copy a record is proportional to its size,
-Berkeley DB includes interfaces that operate on partial records.
-If an application requires only part of a large record,
-it requests partial record retrieval,
-and receives just the bytes that it needs.
-The smaller copy saves both time and memory.
-
-Berkeley DB allows the programmer to define the data types of
-keys and values.
-Developers use any type expressible in the programming language.
-
-A single database managed by Berkeley DB can be up to 248
-bytes,
-or 256 petabytes,
-in size.
-Berkeley DB uses the host filesystem as the backing store
-for the database,
-so large databases require big file support from the operating system.
-Sleepycat Software has customers using Berkeley DB
-to manage single databases in excess of 100 gigabytes.
-
-Applications that do not require persistent storage can create
-databases that exist only in main memory.
-These databases bypass the overhead imposed by the I/O system
-altogether.
-
-Some applications do need to use disk as a backing store,
-but run on machines with very large memory.
-Berkeley DB is able to manage very large shared memory regions
-for cached data pages,
-log records,
-and lock management.
-For example,
-the cache region used for data pages may be gigabytes in size,
-reducing the likelihood that any read operation will need to
-visit the disk in the steady state.
-The programmer declares the size of the cache region at
-startup.
-
-Finally, many operating systems provide memory-mapped file services
-that are much faster than their general-purpose file system
-interfaces.
-Berkeley DB can memory-map its database files for read-only database use.
-The application operates on records stored directly on the pages,
-with no cache management overhead.
-Because the application gets pointers directly into the
-Berkeley DB pages,
-writes cannot be permitted.
-Otherwise,
-changes could bypass the locking and logging systems,
-and software errors could corrupt the database.
-Read-only applications can use Berkeley DB's memory-mapped
-file service to improve performance on most architectures.
-
-Programmers declare the size of the pages used by their access
-methods when they create a database.
-Although Berkeley DB provides reasonable defaults,
-developers may override them to control system performance.
-Small pages reduce the number of records that fit on a single page.
-Fewer records on a page means that fewer records are locked when
-the page is locked,
-improving concurrency.
-The per-page overhead is proportionally higher with smaller pages,
-of course,
-but developers can trade off space for time as an application requires.
-
-Berkeley DB is a compact system.
-The full package, including all access methods, recoverability,
-and transaction support
-is roughly 175K of text space on common architectures.
-
-In database terminology, a cursor is a pointer into an access method
-that can be called iteratively to return records in sequence. Berkeley
-DB includes cursor interfaces for all access methods. This permits,
-for example, users to traverse a B+tree and view records in order.
-Pointers to records in cursors are persistent, so that once fetched,
-a record may be updated in place. Finally, cursors support access to
-chains of duplicate data items in the various access methods.
-
-In database terminology,
-a join is an operation that spans multiple separate
-tables (or in the case of Berkeley DB, multiple separate DB files).
-For example, a company may store information about its customers
-in one table and information about sales in another. An application
-will likely want to look up sales information by customer name; this
-requires matching records in the two tables that share a common
-customer ID field.
-This combining of records from multiple tables is called a join.
-
-Berkeley DB includes interfaces for joining two or more tables.
-
-Transactions have four properties [Gray93]:
-
-This combination of properties -- atomicity, consistency, isolation, and
-durability -- is referred to as ACIDity in the literature. Berkeley DB,
-like most database systems, provides ACIDity using a collection of core
-services.
-
-Programmers can choose to use Berkeley DB's transaction services
-for applications that need them.
-
-Programmers can enable the logging system when they start up Berkeley DB.
-During a transaction,
-the application makes a series of changes to the database.
-Each change is captured in a log entry,
-which holds the state of the database record
-both before and after the change.
-The log record is guaranteed
-to be flushed to stable storage before any of the changed data pages
-are written.
-This behavior -- writing the log before the data pages -- is called
-write-ahead logging.
-
-At any time during the transaction,
-the application can
-commit,
-making the changes permanent,
-or
-roll back,
-cancelling all changes and restoring the database to its
-pre-transaction state.
-If the application
-rolls back the transaction, then the log holds the state of all
-changed pages prior to the transaction, and Berkeley DB simply
-restores that state.
-If the application commits the transaction,
-Berkeley DB writes the log records to disk.
-In-memory copies of the data pages already reflect the changes,
-and will be flushed as necessary during normal processing.
-Since log writes are sequential, but data page
-writes are random, this improves performance.
-
-Berkeley DB's write-ahead log is used by the transaction
-system to commit or roll back transactions.
-It also gives the recovery system the information that
-it needs to protect against data loss or corruption
-from crashes.
-Berkeley DB is able to survive application crashes,
-system crashes,
-and even catastrophic failures like the loss of a hard
-disk,
-without losing any data.
-
-Surviving crashes requires data stored in several different places.
-During normal processing,
-Berkeley DB has copies of active log records and recently-used
-data pages in memory.
-Log records are flushed to the log disk when transactions commit.
-Data pages trickle out to the data disk as pages move through
-the buffer cache.
-Periodically,
-the system administrator backs up the data disk,
-creating a safe copy of the database at a particular instant.
-When the database is backed up,
-the log can be truncated.
-For maximum robustness,
-the log disk and data disk should be separate devices.
-
-Different system failures can destroy memory,
-the log disk,
-or the data disk.
-Berkeley DB is able to survive the loss of any one
-of these repositories
-without losing any committed transactions.
-
-If the computer's memory is lost,
-through an application or operating system crash,
-then the log holds all committed transactions.
-On restart,
-the recovery system rolls the log forward against
-the database,
-reapplying any changes to on-disk pages that were in memory at the
-time of the crash.
-Since the log contains pre- and post-change state for
-transactions,
-the recovery system also uses the log to restore any pages to
-their original state if they were modified by transactions
-that never committed.
-
-If the data disk is lost,
-the system administrator can restore the most recent copy from backup.
-The recovery system will roll the entire log forward against
-the original database,
-reapplying all committed changes.
-When it finishes,
-the database will contain every change made by every
-transaction that ever committed.
-
-If the log disk is lost,
-then the recovery system can use the in-memory copies of
-log entries to roll back any uncommitted transactions,
-flush all in-memory database pages to the data disk,
-and shut down gracefully.
-At that point,
-the system administrator can back up the database disk,
-install a new log disk,
-and restart the system.
-
-Berkeley DB includes a checkpointing service that interacts
-with the recovery system.
-During normal processing,
-both the log and the database are changing continually.
-At any given instant,
-the on-disk versions of the two are not guaranteed to be consistent.
-The log probably contains changes that are not yet in the database.
-
-When an application makes a
-checkpoint,
-all committed changes in the log up to that point
-are guaranteed to be present on the data disk,
-too.
-Checkpointing is moderately expensive during normal processing,
-but limits the time spent recovering from crashes.
-
-After an application or operating system crash,
-the recovery system only needs to go back two checkpoints
-to start rolling the log forward.
-(One checkpoint is not far enough.
-The recovery system cannot be sure that the most recent
-checkpoint completed --
-it may have been interrupted by the crash that forced the
-recovery system to run in the first place.)
-Without checkpoints,
-there is no way to be sure how long restarting after a crash will take.
-With checkpoints,
-the restart interval can be fixed by the programmer.
-Recovery processing can be guaranteed to complete in a second or two.
-
-Software crashes are much more common than disk failures.
-Many developers want to guarantee that software bugs do not destroy data,
-but are willing to restore from tape,
-and to tolerate a day or two of lost work,
-in the unlikley event of a disk crash.
-With Berkeley DB,
-programmers may truncate the log at checkpoints.
-As long as the two most recent checkpoints are present,
-the recovery system can guarantee that no committed transactions
-are lost after a software crash.
-In this case,
-the recovery system does not require that the log and the
-data be on separate devices,
-although separating them can still improve performance
-by spreading out writes.
-
-Berkeley DB provides a service known as two-phase locking.
-In order to reduce the likelihood of deadlocks and to guarantee ACID
-properties, database systems manage locks in two phases. First, during
-the operation of a transaction, they acquire locks, but never release
-them. Second, at the end of the transaction, they release locks, but
-never acquire them. In practice, most database systems, including Berkeley
-DB, acquire locks on demand over the course of the transaction, then
-flush the log, then release all locks.
-
-Berkeley DB can lock entire database files, which correspond to tables,
-or individual pages in them.
-It does no record-level locking.
-By shrinking the page size,
-however,
-developers can guarantee that every page holds only a small
-number of records.
-This reduces contention.
-
-If locking is enabled,
-then read and write operations on a database acquire two-phase locks,
-which are held until the transaction completes.
-Which objects are locked and the order of lock acquisition
-depend on the workload for each transaction.
-It is possible for two or more transactions to deadlock,
-so that each is waiting for a lock that is held by another.
-
-Berkeley DB detects deadlocks and automatically rolls back
-one of the transactions.
-This releases the locks that it held
-and allows the other transactions to continue.
-The caller is notified that its transaction did not complete,
-and may restart it.
-Developers can specify the deadlock detection interval
-and the policy to use in choosing a transaction to roll back.
-
-The two-phase locking interfaces are separately callable by applications
-that link Berkeley DB, though few users have needed to use that facility
-directly.
-Using these interfaces,
-Berkeley DB provides a fast,
-platform-portable locking system for general-purpose use.
-It also lets users include non-database objects in a database transaction,
-by controlling access to them exactly as if they were inside the database.
-
-The Berkeley DB two-phase locking facility is built on the fastest correct
-locking primitives that are supported by the underlying architecture.
-In the current implementation, this means that the locking system is
-different on the various UNIX platforms, and is still more different
-on Windows NT. In our experience, the most difficult aspect of performance
-tuning is finding the fastest locking primitives that work correctly
-on a particular architecture and then integrating the new
-interface with the several that we already support.
-
-The world would be a better place if the operating systems community
-would uniformly implement POSIX locking primitives and would guarantee
-that acquiring an uncontested lock was a fast operation.
-Locks must work both among threads in a single process
-and among processes.
-
-Good performance under concurrent operation is a critical design point
-for Berkeley DB. Although Berkeley DB is itself not multi-threaded,
-it is thread-safe, and runs well in threaded applications.
-Philosophically,
-we view the use of threads and the choice of a threads package
-as a policy decision,
-and prefer to offer mechanism (the ability to run threaded or not),
-allowing applications to choose their own policies.
-
-The locking, logging, and buffer pool subsystems all use shared memory
-or other OS-specific sharing facilities to communicate. Locks, buffer
-pool fetches, and log writes behave in the same way across threads in
-a single process as they do across different processes on a single
-machine.
-
-As a result, concurrent database applications may start up a new process
-for every single user, may create a single server which spawns a new
-thread for every client request, or may choose any policy in between.
-
-Berkeley DB has been carefully designed to minimize contention
-and maximize concurrency.
-The cache manager allows all threads or processes to benefit from
-I/O done by one.
-Shared resources must sometimes be locked for exclusive access
-by one thread of control.
-We have kept critical sections small,
-and are careful not to hold critical resource locks across
-system calls that could deschedule the locking thread or process.
-Sleepycat Software has customers with hundreds of concurrent
-users working on a single database in production.
-
-Fundamentally, Berkeley DB is a collection of access methods with
-important facilities, like logging, locking, and transactional access
-underlying them. In both the research and the commercial world,
-the techniques for building systems like Berkeley DB have been well-known
-for a long time.
-
-The key advantage of Berkeley DB is the careful attention that has been
-paid to engineering details throughout its life. We have carefully
-designed the system so that the core facilities, like locking and I/O,
-surface the right interfaces and are otherwise opaque to the caller.
-As programmers, we understand the value of simplicity and have worked
-hard to simplify the interfaces we surface to users of the
-database system.
-
-Berkeley DB avoids limits in the code. It places no practical limit
-on the size of keys, values, or databases; they may grow to occupy
-the available storage space.
-
-The locking and logging subsystems have been carefully crafted to
-reduce contention and improve throughput by shrinking or eliminating
-critical sections, and reducing the sizes of locked regions and log
-entries.
-
-There is nothing in the design or implementation of Berkeley DB that
-pushes the state of the art in database systems. Rather, we have been
-very careful to get the engineering right. The result is a system that
-is superior, as an embedded database system, to any other solution
-available.
-
-Most database systems trade off simplicity for correctness. Either the
-system is easy to use, or it supports concurrent use and survives system
-failures. Berkeley DB, because of its careful design and implementation,
-offers both simplicity and correctness.
-
-The system has a small footprint,
-makes simple operations simple to carry out (inserting a new record takes
-just a few lines of code), and behaves correctly in the face of heavy
-concurrent use, system crashes, and even catastrophic failures like loss
-of a hard disk.
-
-Berkeley DB is distributed in source code form from
-www.sleepycat.com.
-Users are free to download and build the software, and to use it in
-their applications.
-
-The distribution is a compressed archive file.
-It includes the source code for the Berkeley DB library,
-as well as documentation, test suites, and supporting utilities.
-
-The source code includes build support for all supported platforms.
-On UNIX systems Berkeley DB uses the GNU autoconfiguration tool,
-autoconf,
-to identify the system and to build the library
-and supporting utilities.
-Berkeley DB includes specific build environments for other platforms,
-such as VMS and Windows.
-
-The distributed system includes documentation in HTML format.
-The documentation is in two parts:
-a UNIX-style reference manual for use by programmers,
-and a reference guide which is tutorial in nature.
-
-The software also includes a complete test suite, written in Tcl.
-We believe that the test suite is a key advantage of Berkeley DB
-over comparable systems.
-
-First, the test suite allows users who download and build the software
-to be sure that it is operating correctly.
-
-Second, the test suite allows us, like other commercial developers
-of database software, to exercise the system thoroughly at every
-release. When we learn of new bugs, we add them to the test suite.
-We run the test suite continually during development cycles, and
-always prior to release. The result is a much more reliable system
-by the time it reaches beta release.
-
-Sleepycat makes compiled libraries and general binary distributions available
-to customers for a fee.
-
-Berkeley DB runs on any operating system with a
-POSIX 1003.1 interface [IEEE96],
-which includes virtually every UNIX system.
-In addition,
-the software runs on VMS,
-Windows/95,
-Windows/98,
-and Windows/NT.
-Sleepycat Software no longer supports deployment on sixteen-bit
-Windows systems.
-
-Berkeley DB 2.x is distributed as an Open Source product. The software
-is freely available from us at our Web site, and in other media. Users
-are free to download the software and build applications with it.
-
-The 1.x versions of Berkeley DB were covered by the UC Berkeley copyright
-that covers software freely redistributable in source form. When
-Sleepycat Software was formed, we needed to draft a license consistent
-with the copyright governing the existing, older software. Because
-of important differences between the UC Berkeley copyright and the GPL,
-it was impossible for us to use the GPL.
-A second copyright, with
-terms contradictory to the first, simply would not have worked.
-
-Sleepycat wanted to continue Open Source development of Berkeley DB
-for several reasons.
-We agree with Raymond [Raym98] and others that Open
-Source software is typically of higher quality than proprietary,
-binary-only products.
-Our customers benefit from a community of developers who
-know and use Berkeley DB,
-and can help with application design,
-debugging,
-and performance tuning.
-Widespread distribution and use of the source code tends to
-isolate bugs early,
-and to get fixes back into the distributed system quickly.
-As a result,
-Berkeley DB is more reliable.
-Just as importantly,
-individual users are able to contribute new features
-and performance enhancements,
-to the benefit of everyone who uses Berkeley DB.
-From a business perspective,
-Open Source and free distribution of the
-software creates share for us, and gives us a market into which
-we can sell products and services.
-Finally, making the source code
-freely available reduces our support load, since customers can
-find and fix bugs without recourse to us, in many cases.
-
-To preserve the Open Source heritage of the older Berkeley DB code,
-we drafted a new license governing the distribution of Berkeley DB
-2.x. We adopted terms from the GPL that make it impossible to
-turn our Open Source code into proprietary code owned by someone else.
-
-Briefly, the terms governing the use and distribution of Berkeley DB
-are:
-
-For customers who prefer not to distribute Open Source products,
-we sell licenses to use and extend Berkeley DB at a reasonable cost.
-
-We work hard to accommodate the needs of the Open Source community.
-For example,
-we have crafted special licensing arrangements with Gnome
-to encourage its use and distribution of Berkeley DB.
-
-Berkeley DB conforms to the Open Source definition [Open99].
-The license has
-been carefully crafted to keep the product available as an Open Source
-offering,
-while providing enough of a return on our investment to fund continued
-development and support of the product. The current license has
-created a business capable of funding three years of development on
-the software that simply would not have happened otherwise.
-
-Berkeley DB offers a unique collection of features, targeted squarely
-at software developers who need simple, reliable database management
-services in their applications. Good design and implementation and
-careful engineering throughout make the software better than many
-other systems.
-
-Berkeley DB is an Open Source product, available at
-www.sleepycat.com.
-for download. The distributed system includes everything needed to
-build and deploy the software or to port it to new systems.
-
-Sleepycat Software distributes Berkeley DB under a license agreement
-that draws on both the UC Berkeley copyright and the GPL. The license
-guarantees that Berkeley DB will remain an Open Source product and
-provides Sleepycat with opportunities to make money to fund continued
-development on the software.
-
-Comer, D.,
-"The Ubiquitous B-tree,"
-ACM Computing Surveys
-Volume 11, number 2,
-June 1979.
-
-Gray, J., and Reuter, A.,
-Transaction Processing: Concepts and Techniques,
-Morgan-Kaufman Publishers,
-1993.
-
-Institute for Electrical and Electronics Engineers,
-IEEE/ANSI Std 1003.1,
-1996 Edition.
-
-Litwin, W.,
-"Linear Hashing: A New Tool for File and Table Addressing,"
-Proceedings of the 6th International Conference on Very Large Databases (VLDB),
-Montreal, Quebec, Canada,
-October 1980.
-
-The Open Group,
-Distributed TP: The XA+ Specification, Version 2,
-The Open Group, 1994.
-
-Opensource.org,
-"Open Source Definition,"
-www.opensource.org/osd.html,
-version 1.4,
-1999.
-
-Raymond, E.S.,
-"The Cathedral and the Bazaar,"
-
-www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html,
-January 1998.
-
-Seltzer, M., and Yigit, O.,
-"A New Hashing Package for UNIX,"
-Proceedings 1991 Winter USENIX Conference,
-Dallas, TX,
-January 1991.
-
-Seltzer, M., and Olson, M.,
-"LIBTP: Portable Modular Transactions for UNIX,"
-Proceedings 1992 Winter Usenix Conference
-San Francisco, CA,
-January 1992.]
-
-Stonebraker, M., Stettner, H., Kalash, J., Guttman, A., and Lynn, N.,
-"Document Processing in a Relational Database System,"
-Memorandum No. UCB/ERL M82/32,
-University of California at Berkeley,
-Berkeley, CA,
-May 1982.
-
-Database configuration and maintenance have historically been complex tasks,
-often
-requiring expert knowledge of database design and application
-behavior.
-In an embedded environment, it is not feasible to require such
-expertise and ongoing database maintenance.
-This paper discusses the database administration
-challenges posed by embedded systems and describes how the
-Berkeley DB architecture addresses these challenges.
-
-
-Database administration consists of two components,
-initial configuration and ongoing maintenance.
-Initial configuration consists of database design, manifestation,
-and tuning.
-The instantiation of the design includes decomposing the design
-into tables, relations, or objects and designating proper indices
-and their implementations (e.g., Btrees, hash tables, etc.).
-Tuning a design requires selecting a location for the log and
-data files, selecting appropriate database page sizes, specifying
-the size of in-memory caches, and specifying the limits of
-multi-threading and concurrency.
-As embedded systems define a specific environment and set of tasks,
-requiring expertise during the initial system
-configuration process is acceptable, and we focus our efforts on
-the ongoing maintenance of the system.
-In this way, our emphasis differs from other projects such as
-Microsoft's AutoAdmin project [3], and the "no-knobs"
-administration that is identified as an area of important future
-research by the Asilomar authors[1].
-
-In this paper, we focus on what the authors
-of the Asilomar report call "gizmo" databases [1],
-databases
-that reside in devices such as smart cards, toasters, or telephones.
-The key characteristics of such databases are that their
-functionality is completely transparent to users, no one ever
-performs explicit database operations or
-database maintenance, the database may crash at any time and
-must recover instantly, the device may undergo a hard reset at
-any time, requiring that the database return to its initial
-state, and the semantic integrity of the database must be maintained
-at all times.
-In Section 2, we provide more detail on the sorts of tasks
-typically performed by database administrators (DBAs) that must
-be automated in an embedded system.
-
-The rest of this paper is structured as follows.
-In Section 2, we outline the requirements for embedded database support.
-In Section 3, we discuss how Berkeley DB
-is conducive to the hands-off management
-required in embedded systems.
-In Section 4, we discuss novel features that
-enhance Berkeley
-DB's suitability for the embedded applications.
-In Section 5, we discuss issues of footprint size.
-In Section 6 we discuss related work, and we conclude
-in Section 7.
-
-
-In the embedded database arena, it is the ongoing maintenance tasks
-that must be automated, not necessarily the initial system configuration.
-There are five tasks
-that are traditionally performed by DBAs,
-but must be performed automatically
-in embedded database systems.
-These tasks are
-log archival and reclamation,
-backup,
-data compaction/reorganization,
-automatic and rapid recovery, and
-reinitialization from scratch.
-
-Log archival and backup are tightly coupled.
-Database backups are part of any
-large database installation, and log archival is analogous to incremental
-backup.
-It is not clear what the implications of backup and archival are in
-an embedded system.
-Consumers do not back up their VCRs or refrigerators, yet they do
-(or should) back up their personal computers or personal digital
-assistants.
-For the remainder of this paper, we assume that backups, in some form,
-are required for gizmo databases (imagine having to reprogram, manually,
-the television viewing access pattern learned by some set-top television
-systems today).
-Furthermore, we require that those backups are nearly instantaneous or
-completely transparent,
-as users should not be aware that their gizmos are being backed up
-and should not have to explicitly initiate such backups.
-
-Data compaction or reorganization has traditionally required periodic
-dumping and restoration of
-database tables and the recreation of indices.
-In an embedded system, such reorganization must happen automatically.
-
-Recovery issues are similar in embedded and traditional environments
-with a few exceptions.
-While a few seconds or even a minute recovery is acceptable
-for a large server installation, no one is willing to wait
-for their telephone or television to reboot.
-As with archival, recovery must be nearly instantaneous in an embedded product.
-Secondly, it is often the case that a system will be completely
-reinitialized, rather than simply rebooted.
-In this case, the embedded database must be restored to its initial
-state, freeing all its resources.
-This is not typically a requirement of large server systems.
-
-In addition to the maintenance-free operation required of the
-embedded systems, there are a number of requirements that fall
-out of the constrained resources typically found in the "gizmos"
-using gizmo databases. These requirements are:
-small footprint,
-short code-path,
-programmatic interface for tight application coupling and
-to avoid the overhead (in both time and size) of
-interfaces such as SQL and ODBC,
-application configurability and flexibility,
-support for complete memory-resident operation (e.g., these systems
-must run on gizmos without file systems), and
-support for multi-threading.
-
-A small footprint and short code-path are self-explanatory, however
-what is not as obvious is that the programmatic interface requirement
-is the logical result of them.
-Traditional interfaces such as ODBC and SQL add significant
-size overhead and frequently add multiple context/thread switches
-per operation, not to mention several IPC calls.
-An embedded product is less likely to require the complex
-query processing that SQL enables.
-Instead, in the embedded space, the ability for an application
-to configure the database for the specific tasks in question
-is more important than a general query interface.
-
-As some systems do not provide storage other than RAM and ROM,
-it is essential that an embedded database work seemlessly
-in memory-only environments.
-Similarly, many of today's embedded operating systems provide a
-single address space architecture, so a simple, multi-threaded
-capability is essential for application requiring any concurrency.
-
-In general, embedded applications run on gizmos whose native
-operating system support varies tremendously.
-For example, the embedded OS may or may
-not support user-level processing or multi-threading.
-Even if it does, a particular embedded
-application may or may not need it.
-Not all applications need more than one thread of control.
-An embedded database must provide mechanisms to developers
-without deciding policy.
-For example, the threading model in an application is a matter of policy,
-and depends
-not on the database software, but on the hardware, operating
-system, and the application's feature set.
-Therefore, the data manager must provide for the use of multi-threading,
-but not require it.
-
-
-Versions 2.X and higher are distributed by Sleepycat Software and
-add functionality for concurrency, logging, transactions, and
-recovery.
-Each piece of additional functionality is implemented as an independent
-module, which means that the subsystems can be used outside the
-context of Berkeley DB. For example, the locking subsystem can
-easily be used to implement locking for a non-DB application and
-the shared memory buffer pool can be used for any application
-caching data in main memory.
-This subsystem design allows a designer to pick and choose
-the functionality necessary for the application, minimizing
-memory footprint and maximizing performance.
-This addresses the small footprint and short code-path criteria
-mentioned in the previous section.
-
-As Berkeley DB grew out of a replacement for dbm, its primary
-implementation language has always been C and its interface has
-been programmatic. The C interface is the native interface,
-unlike many database systems where the programmatic API is simply
-a layer on top of an already-costly query interface (e.g. embedded
-SQL).
-Berkeley DB's heritage is also apparent in its data model; it has
-none.
-The database stores unstructured key/data pairs, specified as
-variable length byte strings.
-This leaves schema design and representation issues the responsibility
-of the application, which is ideal for an embedded environment.
-Applications retain full control over specification of their data
-types, representation, index values, and index relationships.
-In other words, Berkeley DB provides a robust, high-performance,
-keyed storage system, not a particular database management system.
-We have designed for simplicity and performance, trading off
-complex, general purpose support that is better encapsulated in
-applications.
-
-Another element of Berkeley DB's programmatic interface is its
-customizability; applications can specify Btree comparison and
-prefix compression functions, hash functions, error routines,
-and recovery models.
-This means that embedded applications can tailor the underlying
-database to best suit their data demands.
-Similarly, the utilities traditionally bundled with a database
-manager (e.g., recovery, dump/restore, archive) are implemented
-as tiny wrapper programs around library routines. This means
-that it is not necessary to run separate applications for the
-utilities. Instead, independent threads can act as utility
-daemons, or regular query threads can perform utility functions.
-Many of the current products built on Berkeley DB are bundled as
-a single large server with independent threads that perform functions
-such as checkpoint, deadlock detection, and performance monitoring.
-
-As mentioned earlier, living in an embedded environment requires
-flexible management of storage.
-Berkeley DB does not require any preallocation of disk space
-for log or data files.
-While many commercial database systems take complete control
-of a raw device, Berkeley DB uses a normal file system, and
-can therefore, safely and easily share a data space with other
-programs.
-All databases and log files are native files of the host environment,
-so whatever utilities are provided by the environment can be used
-to manage database files as well.
-
-Berkeley DB provides three different memory models for its
-management of shared information.
-Applications can use the IEEE Std 1003.1b-1993 (POSIX) mmap
-interface to share
-data, they can use system shared memory, as frequently provided
-by the shmget family of interfaces, or they can use per-process
-heap memory (e.g., malloc).
-Applications that require no permanent storage and do not provide
-shared memory facilities can still use Berkeley DB by requesting
-strictly private memory and specifying that all databases be
-memory-resident.
-This provides pure-memory operation.
-
-Lastly, Berkeley DB is designed for rapid startup -- recovery can
-happen automatically as part of system initialization.
-This means that Berkeley DB works correctly in environments where
-gizmos are suddenly shut down and restarted.
-
-
-As applications are also permitted to specify comparison and hash
-functions, the application can chose to organize its data based
-either on uncompressed and clear-text data or compressed and encrypted
-data.
-If the application indicates that data should be compared in its
-processed form (i.e., compressed and encrypted), then the compression
-and encryption are performed on individual data items and the in-memory
-representation retains these characteristics.
-However, if the application indicates that data should be compared in
-its original form, then entire pages are transformed upon being read
-into or written out of the main memory buffer cache.
-These two alternatives provide the flexibility to trade space
-and security for performance.
-
-
-Berkeley DB provides an option to perform coarser grain,
-deadlock-free locking.
-Rather than locking on pages, locking is performed at the
-interface to the database.
-Multiple readers or a single writer are allowed to be
-active in the database at any instant in time, with
-conflicting requests queued automatically.
-The presence of cursors, through which applications can both
-read and write data, complicates this design.
-If a cursor is currently being used for reading, but will later
-be used to write, the system will be deadlock prone if no
-special precautions are taken.
-To handle this situation, we require that, when a cursor is
-created, the application specify any future intention to write.
-If there is an intention to write, the cursor is granted an
-intention-to-write lock which does not conflict with readers,
-but does conflict with other intention-to-write locks and write
-locks.
-The end result is that the application is limited to a single
-potentially writing cursor accessing the database at any point
-in time.
-
-Under periods of low contention (but potentially high throughput),
-the normal page-level locking provides the best overall throughput.
-However, as contention rises, so does the potential for deadlock.
-As some cross-over point, switching to the less concurrent, but
-deadlock-free locking protocol will result in higher throughput
-as operations must never be retried.
-Given the operating conditions of an embedded database manager,
-it is useful to make this change automatically as the system
-itself detects high contention.
-
-
-Oracle reports that Oracle Lite 3.0 requires 350 KB to 750 KB
-of memory and approximately 2.5 MB of hard disk space [7].
-This includes drivers for interfaces such as ODBC and JDBC.
-In contrast, Berkeley DB ranges in size from 75 KB to under 200 KB,
-foregoing heavyweight interfaces such as ODBC and JDBC and
-providing a variety of deployed sizes that can be used depending
-on application needs. At the low end, applications requiring
-a simple single-user access method can choose from either extended
-linear hashing, B+ trees, or record-number based retrieval and
-pay only the 75 KB space requirement.
-Applications requiring all three access methods will observe the
-110 KB footprint.
-At the high end, a fully recoverable, high-performance system
-occupies less than a quarter megabyte of memory.
-This is a system you can easily incorporate in your toaster oven.
-Table 1 shows the per-module break down of the entire Berkeley DB
-library. Note that this does not include memory used to cache database
-pages.
-
-
-The Asilomar report identifies a new class of database applications, which they
-term "gizmo" databases, small databases embedded in tiny mobile
-appliances, e.g., smart-cards, telephones, personal digital assistants.
-Such databases must be self-managing, secure and reliable.
-Thus, the idea is that gizmo databases require plug and play data
-management with no database administrator (DBA), no human settable
-parameters, and the ability to adapt to changing conditions.
-More specifically, the Asilomar authors claim that the goal is
-self-tuning, including defining the physical DB design, the
-logical DB design, and automatic reports and utilities [1]
-To date,
-few researchers have accepted this challenge, and there is a dearth
-of research literature on the subject.
-
-Our approach to embedded database administration is fundamentally
-different than that described by the Asilomar authors.
-We adopt their terminology, but view the challenge in supporting
-gizmo databases to be that of self-sustenance after initial
-deployment. Therefore, we find it, not only acceptable, but
-desirable to assume that application developers control initial
-database design and configuration. To the best of our knowledge,
-none of the published work in this area addresses this approach.
-
-As the research community has not provided guidance in this
-arena, most work in embedded database administration has fallen
-to the commercial vendors.
-These vendors fall into two camps, companies selling databases
-specifically designed for embedding or programmatic access
-and the major database vendors (e.g., Oracle, Informix, Sybase).
-
-The embedded vendors all acknowledge the need for automatic
-administration, but fail to identify precisely how their
-products actually accomplish this.
-A notable exception is Interbase whose white paper
-comparison with Sybase and Microsoft's SQL servers
-explicitly address features of maintenance ease.
-Interbase claims that as they use no log files, there is
-no need for log reclamation, checkpoint tuning, or other
-tasks associated with log management. However, Interbase
-uses Transaction Information Pages, and it is unclear
-how these are reused or reclaimed [6].
-Additionally, with a log-free system, they must use
-a FORCE policy (write all pages to disk at commit),
-as defined by Haerder and Reuter [4]. This has
-serious performance consequences for disk-based systems.
-The approach described in this paper does use logs and
-therefore requires log reclamation,
-but provides hooks so the application may reclaim logs
-safely and programmatically.
-While Berkeley DB does require checkpoints, the goal of
-tuning the checkpoint interval is to bound recovery time.
-Since the checkpoint interval in Berkeley DB can be expressed
-by the amount of log data written, it requires no tuning.
-The application designer sets a target recovery time, and
-selects the amount of log data that can be read in that interval
-and specifies the checkpoint interval appropriately. Even as
-load changes, the time to recover does not.
-
-The backup approaches taken by Interbase and Berkeley DB
-are similar in that they both allow online backup, but
-rather different in their affect on transactions running
-during backup. As Interbase performs backups as transactions
-[6], concurrent queries can suffer potentially long
-delays. Berkeley DB uses native operating system system utilities
-and recovery for backups, so there is no interference with
-concurrent activity, other than potential contention on disk
-arms.
-
-There are a number of database vendors selling in
-the embedded market (e.g., Raima,
-Centura, Pervasive, Faircom), but none highlight
-the special requirements of embedded database
-applications.
-On the other end of the spectrum, the major vendors,
-Oracle, Sybase, Microsoft, are all becoming convinced
-of the importance of the embedded market.
-As mentioned earlier, Oracle has announced its
-Oracle Lite server for embedded use.
-Sybase has announced its UltraLite platform for "application-optimized,
-high-performance, SQL database engine for professional
-application developers building solutions for mobile and embedded platforms."
-[8].
-We believe that SQL is incompatible with the
-gizmo database environment or truly embedded systems for which Berkeley
-DB is most suitable.
-Microsoft research is taking a different approach, developing
-technology to assist in automating initial database design and
-index specification [2][3].
-As mentioned earlier, we believe that such configuration is, not only
-acceptable in the embedded market, but desirable so that applications
-can tune their database management for the target environment.
-
-[8] Sybase, Sybase UltraLite, http://www.sybase.com/products/ultralite/beta.
-
-
-[10] Transaction Processing Council, "TPC-D Benchmark Specification,
-Version 2.1," San Jose, CA, April 1999.
-
-
-
-
-
diff --git a/bdb/docs/ref/refs/hash_usenix.ps b/bdb/docs/ref/refs/hash_usenix.ps
deleted file mode 100644
index c884778830d..00000000000
--- a/bdb/docs/ref/refs/hash_usenix.ps
+++ /dev/null
@@ -1,12209 +0,0 @@
-%!PS-Adobe-1.0
-%%Creator: utopia:margo (& Seltzer,608-13E,8072,)
-%%Title: stdin (ditroff)
-%%CreationDate: Tue Dec 11 15:06:45 1990
-%%EndComments
-% @(#)psdit.pro 1.3 4/15/88
-% lib/psdit.pro -- prolog for psdit (ditroff) files
-% Copyright (c) 1984, 1985 Adobe Systems Incorporated. All Rights Reserved.
-% last edit: shore Sat Nov 23 20:28:03 1985
-% RCSID: $Header: psdit.pro,v 2.1 85/11/24 12:19:43 shore Rel $
-
-% Changed by Edward Wang (edward@ucbarpa.berkeley.edu) to handle graphics,
-% 17 Feb, 87.
-
-/$DITroff 140 dict def $DITroff begin
-/fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def
-/xi{0 72 11 mul translate 72 resolution div dup neg scale 0 0 moveto
- /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def F
- /pagesave save def}def
-/PB{save /psv exch def currentpoint translate
- resolution 72 div dup neg scale 0 0 moveto}def
-/PE{psv restore}def
-/arctoobig 90 def /arctoosmall .05 def
-/m1 matrix def /m2 matrix def /m3 matrix def /oldmat matrix def
-/tan{dup sin exch cos div}def
-/point{resolution 72 div mul}def
-/dround {transform round exch round exch itransform}def
-/xT{/devname exch def}def
-/xr{/mh exch def /my exch def /resolution exch def}def
-/xp{}def
-/xs{docsave restore end}def
-/xt{}def
-/xf{/fontname exch def /slotno exch def fontnames slotno get fontname eq not
- {fonts slotno fontname findfont put fontnames slotno fontname put}if}def
-/xH{/fontheight exch def F}def
-/xS{/fontslant exch def F}def
-/s{/fontsize exch def /fontheight fontsize def F}def
-/f{/fontnum exch def F}def
-/F{fontheight 0 le{/fontheight fontsize def}if
- fonts fontnum get fontsize point 0 0 fontheight point neg 0 0 m1 astore
- fontslant 0 ne{1 0 fontslant tan 1 0 0 m2 astore m3 concatmatrix}if
- makefont setfont .04 fontsize point mul 0 dround pop setlinewidth}def
-/X{exch currentpoint exch pop moveto show}def
-/N{3 1 roll moveto show}def
-/Y{exch currentpoint pop exch moveto show}def
-/S{show}def
-/ditpush{}def/ditpop{}def
-/AX{3 -1 roll currentpoint exch pop moveto 0 exch ashow}def
-/AN{4 2 roll moveto 0 exch ashow}def
-/AY{3 -1 roll currentpoint pop exch moveto 0 exch ashow}def
-/AS{0 exch ashow}def
-/MX{currentpoint exch pop moveto}def
-/MY{currentpoint pop exch moveto}def
-/MXY{moveto}def
-/cb{pop}def % action on unknown char -- nothing for now
-/n{}def/w{}def
-/p{pop showpage pagesave restore /pagesave save def}def
-/Dt{/Dlinewidth exch def}def 1 Dt
-/Ds{/Ddash exch def}def -1 Ds
-/Di{/Dstipple exch def}def 1 Di
-/Dsetlinewidth{2 Dlinewidth mul setlinewidth}def
-/Dsetdash{Ddash 4 eq{[8 12]}{Ddash 16 eq{[32 36]}
- {Ddash 20 eq{[32 12 8 12]}{[]}ifelse}ifelse}ifelse 0 setdash}def
-/Dstroke{gsave Dsetlinewidth Dsetdash 1 setlinecap stroke grestore
- currentpoint newpath moveto}def
-/Dl{rlineto Dstroke}def
-/arcellipse{/diamv exch def /diamh exch def oldmat currentmatrix pop
- currentpoint translate 1 diamv diamh div scale /rad diamh 2 div def
- currentpoint exch rad add exch rad -180 180 arc oldmat setmatrix}def
-/Dc{dup arcellipse Dstroke}def
-/De{arcellipse Dstroke}def
-/Da{/endv exch def /endh exch def /centerv exch def /centerh exch def
- /cradius centerv centerv mul centerh centerh mul add sqrt def
- /eradius endv endv mul endh endh mul add sqrt def
- /endang endv endh atan def
- /startang centerv neg centerh neg atan def
- /sweep startang endang sub dup 0 lt{360 add}if def
- sweep arctoobig gt
- {/midang startang sweep 2 div sub def /midrad cradius eradius add 2 div def
- /midh midang cos midrad mul def /midv midang sin midrad mul def
- midh neg midv neg endh endv centerh centerv midh midv Da
- Da}
- {sweep arctoosmall ge
- {/controldelt 1 sweep 2 div cos sub 3 sweep 2 div sin mul div 4 mul def
- centerv neg controldelt mul centerh controldelt mul
- endv neg controldelt mul centerh add endh add
- endh controldelt mul centerv add endv add
- centerh endh add centerv endv add rcurveto Dstroke}
- {centerh endh add centerv endv add rlineto Dstroke}
- ifelse}
- ifelse}def
-/Dpatterns[
-[%cf[widthbits]
-[8<0000000000000010>]
-[8<0411040040114000>]
-[8<0204081020408001>]
-[8<0000103810000000>]
-[8<6699996666999966>]
-[8<0000800100001008>]
-[8<81c36666c3810000>]
-[8<0f0e0c0800000000>]
-[8<0000000000000010>]
-[8<0411040040114000>]
-[8<0204081020408001>]
-[8<0000001038100000>]
-[8<6699996666999966>]
-[8<0000800100001008>]
-[8<81c36666c3810000>]
-[8<0f0e0c0800000000>]
-[8<0042660000246600>]
-[8<0000990000990000>]
-[8<0804020180402010>]
-[8<2418814242811824>]
-[8<6699996666999966>]
-[8<8000000008000000>]
-[8<00001c3e363e1c00>]
-[8<0000000000000000>]
-[32<00000040000000c00000004000000040000000e0000000000000000000000000>]
-[32<00000000000060000000900000002000000040000000f0000000000000000000>]
-[32<000000000000000000e0000000100000006000000010000000e0000000000000>]
-[32<00000000000000002000000060000000a0000000f00000002000000000000000>]
-[32<0000000e0000000000000000000000000000000f000000080000000e00000001>]
-[32<0000090000000600000000000000000000000000000007000000080000000e00>]
-[32<00010000000200000004000000040000000000000000000000000000000f0000>]
-[32<0900000006000000090000000600000000000000000000000000000006000000>]]
-[%ug
-[8<0000020000000000>]
-[8<0000020000002000>]
-[8<0004020000002000>]
-[8<0004020000402000>]
-[8<0004060000402000>]
-[8<0004060000406000>]
-[8<0006060000406000>]
-[8<0006060000606000>]
-[8<00060e0000606000>]
-[8<00060e000060e000>]
-[8<00070e000060e000>]
-[8<00070e000070e000>]
-[8<00070e020070e000>]
-[8<00070e020070e020>]
-[8<04070e020070e020>]
-[8<04070e024070e020>]
-[8<04070e064070e020>]
-[8<04070e064070e060>]
-[8<06070e064070e060>]
-[8<06070e066070e060>]
-[8<06070f066070e060>]
-[8<06070f066070f060>]
-[8<060f0f066070f060>]
-[8<060f0f0660f0f060>]
-[8<060f0f0760f0f060>]
-[8<060f0f0760f0f070>]
-[8<0e0f0f0760f0f070>]
-[8<0e0f0f07e0f0f070>]
-[8<0e0f0f0fe0f0f070>]
-[8<0e0f0f0fe0f0f0f0>]
-[8<0f0f0f0fe0f0f0f0>]
-[8<0f0f0f0ff0f0f0f0>]
-[8<1f0f0f0ff0f0f0f0>]
-[8<1f0f0f0ff1f0f0f0>]
-[8<1f0f0f8ff1f0f0f0>]
-[8<1f0f0f8ff1f0f0f8>]
-[8<9f0f0f8ff1f0f0f8>]
-[8<9f0f0f8ff9f0f0f8>]
-[8<9f0f0f9ff9f0f0f8>]
-[8<9f0f0f9ff9f0f0f9>]
-[8<9f8f0f9ff9f0f0f9>]
-[8<9f8f0f9ff9f8f0f9>]
-[8<9f8f1f9ff9f8f0f9>]
-[8<9f8f1f9ff9f8f1f9>]
-[8
- For more information on Berkeley DB, or on database systems theory in general,
-we recommend the sources listed below.
- These papers have appeared in refereed conference proceedings, and are
-subject to copyrights held by the conference organizers and the authors
-of the papers. Sleepycat Software makes them available here as a courtesy
-with the permission of the copyright holders.
- These papers, while not specific to Berkeley DB, give a good overview of how
-different Berkeley DB features were implemented.
- These publications are standard reference works on the design and
-implementation of database systems. Berkeley DB uses many of the ideas they
-describe.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/refs/witold.html b/bdb/docs/ref/refs/witold.html
deleted file mode 100644
index d81065e66c4..00000000000
--- a/bdb/docs/ref/refs/witold.html
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/rpc/client.html b/bdb/docs/ref/rpc/client.html
deleted file mode 100644
index e8eb90dcfe1..00000000000
--- a/bdb/docs/ref/rpc/client.html
+++ /dev/null
@@ -1,75 +0,0 @@
-
-
-
-
-
- Changing a Berkeley DB application to remotely call a server program requires
-only a few changes on the client side:
- The client application provides three pieces of information to Berkeley DB as
-part of the DBENV->set_server call:
- The only other item of interest to the client is the home directory
-that is given to the DBENV->open call.
-The server is started with a list of allowed home directories.
-The client must use one of those names (where a name is the last
-component of the home directory). This allows the pathname structure
-on the server to change without client applications needing to be
-aware of it.
- Once the DBENV->set_server call has been made, the client is
-connected to the server and all subsequent Berkeley DB
-operations will be forwarded to the server. The client does not need to
-be otherwise aware that it is using a database server rather than
-accessing the database locally.
- It is important to realize that the client portion of the Berkeley DB library
-acts as a simple conduit, forwarding Berkeley DB interface arguments to the
-server without interpretation. This has two important implications.
-First, all pathnames must be specified relative to the server. For
-example, the home directory and other configuration information passed by
-the application when creating its environment or databases must be
-pathnames for the server, not the client system. In addition, as there
-is no logical bundling of operations at the server, performance is usually
-significantly less than when Berkeley DB is embedded within the client's address
-space, even if the RPC is to a local address.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/rpc/intro.html b/bdb/docs/ref/rpc/intro.html
deleted file mode 100644
index 25e4f4aea61..00000000000
--- a/bdb/docs/ref/rpc/intro.html
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-
-
-
- Berkeley DB includes a basic implementation of a client-server protocol, using
-Sun Microsystem's Remote Procedure Call Protocol. RPC support is only
-available for UNIX systems, and is not included in the Berkeley DB library by
-default, but must be enabled during configuration. See
-Configuring Berkeley DB for more
-information. For more information on RPC itself, see your UNIX system
-documentation or RPC: Remote Procedure Call Protocol
-Specification, RFC1832, Sun Microsystems, Inc., USC-ISI.
- Only some of the complete Berkeley DB functionality is available when using RPC.
-The following functionality is available:
- The RPC client/server code does not support any of the user-defined
-comparison or allocation functions, e.g., an application using the RPC
-support may not specify its own Btree comparison function. If your
-application only requires those portions of Berkeley DB, then using RPC is
-fairly simple. If your application requires other Berkeley DB functionality,
-such as direct access to locking, logging or shared memory buffer memory
-pools, then your application cannot use the RPC support.
- The Berkeley DB RPC support does not provide any security or authentication of
-any kind. Sites needing any kind of data security measures must modify
-the client and server code to provide whatever level of security they
-require.
- One particularly interesting use of the RPC support is for debugging Berkeley DB
-applications. The seamless nature of the interface means that with very
-minor application code changes, an application can run outside of the
-Berkeley DB address space, making it far easier to track down many types of
-errors such as memory misuse.
- Using the RPC mechanisms in Berkeley DB involves two basic steps:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/rpc/server.html b/bdb/docs/ref/rpc/server.html
deleted file mode 100644
index 64572a90d30..00000000000
--- a/bdb/docs/ref/rpc/server.html
+++ /dev/null
@@ -1,54 +0,0 @@
-
-
-
-
-
- The Berkeley DB server utility, berkeley_db_svc, handles all of the
-client application requests.
- Currently, the berkeley_db_svc utility is single-threaded,
-limiting the number of requests that it can handle. Modifying the server
-implementation to run in multi-thread or multi-process mode will require
-modification of the server code automatically generated by the rpcgen
-program.
- There are two different types of timeouts used by berkeley_db_svc.
-The first timeout (which can be modified within some constraints by the
-client application), is the resource timeout. When clients use
-transactions or cursors, those resources hold locks in Berkeley DB across calls
-to the server. If a client application dies or loses its connection to
-the server while holding those resources, it prevents any other client
-from acquiring them. Therefore, it is important to detect that a client
-has not used a resource for some period of time and release them. In the
-case of transactions, the server aborts the transaction. In the case of
-cursors, the server closes the cursor.
- The second timeout is an idle timeout. A client application may remain
-idle with an open handle to an environment and a database. Doing so
-simply consumes some memory, it does not hold locks. However, the Berkeley DB
-server may want to eventually reclaim resources if a client dies or
-remains disconnected for a long period of time, so there is a separate
-idle timeout for open Berkeley DB handles.
- The list of home directories specified to berkeley_db_svc are the
-only ones client applications are allowed to use. When
-berkeley_db_svc is started, it is given a list of pathnames.
-Clients are expected to specify the name of the home directory (defined
-as the last component in the directory pathname) as the database
-environment they are opening. In this manner, clients need only know the
-name of their home environment, and not its full pathname on the server
-machine. This means, of course, that only one environment of a particular
-name is allowed on the server at any given time.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/sendmail/intro.html b/bdb/docs/ref/sendmail/intro.html
deleted file mode 100644
index 9dc1b4a141e..00000000000
--- a/bdb/docs/ref/sendmail/intro.html
+++ /dev/null
@@ -1,51 +0,0 @@
-
-
-
-
-
- If you are attempting to use Berkeley DB with Sendmail 8.8.X, you must use
-Berkeley DB version 1.85 (see the Sleepycat Software web site's
-historic releases
-of Berkeley DB page for more information.
- Berkeley DB versions 2.0 and later are only supported by Sendmail versions 8.9.X
-and later.
- Berkeley DB versions 3.0 and later are only supported by Sendmail versions
-8.10.X and later.
- We strongly recommend that you not use Berkeley DB version 1.85. It is no longer
-maintained or supported and has known bugs that can cause Sendmail to
-fail. Instead, please upgrade to Sendmail version 8.9.X or later and use
-a later version of Berkeley DB. For more information on using Berkeley DB with
-Sendmail, please review the README and src/README files in the Sendmail
-distribution.
- To load sendmail against Berkeley DB, add the following lines to
-BuildTools/Site/site.config.m4:
- where those are the paths to #include <db.h> and libdb.a respectively.
-Then, run "Build -c" from the src directory.
- Note that this Build script will use -DNEWDB on the compiles
-and -L/path/to/libdb/directory -ldb on the link if it can find libdb.a;
-the search path is $LIBDIRS:/lib:/usr/lib:/usr/shlib. $LIBDIRS is
-NULL by default for most systems, but some set it in BuildTools/OS/foo.
-Anyone can append to it as above (confLIBDIRS is the m4 variable name;
-LIBDIRS is the shell-script variable name).
- To download Sendmail, or to obtain more information on Sendmail, see the
-Sendmail home page, which includes
-FAQ pages and problem addresses.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/close.html b/bdb/docs/ref/simple_tut/close.html
deleted file mode 100644
index a268a591c7d..00000000000
--- a/bdb/docs/ref/simple_tut/close.html
+++ /dev/null
@@ -1,102 +0,0 @@
-
-
-
-
-
- The only other operation that we need for our simple example is closing
-the database, and cleaning up the DB handle.
- It is necessary that the database be closed. The most important reason
-for this is that Berkeley DB runs on top of an underlying buffer cache. If
-the modified database pages are never explicitly flushed to disk and
-the database is never closed, changes made to the database may never
-make it out to disk, because they are held in the Berkeley DB cache. As the
-default behavior of the close function is to flush the Berkeley DB cache,
-closing the database will update the on-disk information.
- The DB->close interface takes two arguments:
- Here's what the code to call DB->close looks like:
-
-#define DATABASE "access.db"
-
-int
-main()
-{
- DB *dbp;
- DBT key, data;
- int ret, t_ret;
-
- if ((ret = db_create(&dbp, NULL, 0)) != 0) {
- fprintf(stderr, "db_create: %s\n", db_strerror(ret));
- exit (1);
- }
- if ((ret = dbp->open(
- dbp, DATABASE, NULL, DB_BTREE, DB_CREATE, 0664)) != 0) {
- dbp->err(dbp, ret, "%s", DATABASE);
- goto err;
- }
-
- memset(&key, 0, sizeof(key));
- memset(&data, 0, sizeof(data));
- key.data = "fruit";
- key.size = sizeof("fruit");
- data.data = "apple";
- data.size = sizeof("apple");
-
- if ((ret = dbp->put(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key stored.\n", (char *)key.data);
- else {
- dbp->err(dbp, ret, "DB->put");
- goto err;
- }
-
- if ((ret = dbp->get(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key retrieved: data was %s.\n",
- (char *)key.data, (char *)data.data);
- else {
- dbp->err(dbp, ret, "DB->get");
- goto err;
- }
-
- if ((ret = dbp->del(dbp, NULL, &key, 0)) == 0)
- printf("db: %s: key was deleted.\n", (char *)key.data);
- else {
- dbp->err(dbp, ret, "DB->del");
- goto err;
- }
-
- if ((ret = dbp->get(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key retrieved: data was %s.\n",
- (char *)key.data, (char *)data.data);
- else
- dbp->err(dbp, ret, "DB->get");
- err: if ((t_ret = dbp->close(dbp, 0)) != 0 && ret == 0)
- ret = t_ret;
-
- exit(ret);
-}
- Note that we do not necessarily overwrite the ret variable, as it
-may contain error return information from a previous Berkeley DB call.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/del.html b/bdb/docs/ref/simple_tut/del.html
deleted file mode 100644
index ac4d4126033..00000000000
--- a/bdb/docs/ref/simple_tut/del.html
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
-
-
-
- The simplest way to remove elements from a database is the DB->del
-interface.
- The DB->del interface takes four of the same five arguments that
-the DB->get and DB->put interfaces take. The difference
-is that there is no need to specify a data item, as the delete operation
-is only interested in the key that you want to remove.
- Here's what the code to call DB->del looks like:
-
-#define DATABASE "access.db"
-
-int
-main()
-{
- DB *dbp;
- DBT key, data;
- int ret;
-
- if ((ret = db_create(&dbp, NULL, 0)) != 0) {
- fprintf(stderr, "db_create: %s\n", db_strerror(ret));
- exit (1);
- }
- if ((ret = dbp->open(
- dbp, DATABASE, NULL, DB_BTREE, DB_CREATE, 0664)) != 0) {
- dbp->err(dbp, ret, "%s", DATABASE);
- goto err;
- }
-
- memset(&key, 0, sizeof(key));
- memset(&data, 0, sizeof(data));
- key.data = "fruit";
- key.size = sizeof("fruit");
- data.data = "apple";
- data.size = sizeof("apple");
-
- if ((ret = dbp->put(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key stored.\n", (char *)key.data);
- else {
- dbp->err(dbp, ret, "DB->put");
- goto err;
- }
-
- if ((ret = dbp->get(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key retrieved: data was %s.\n",
- (char *)key.data, (char *)data.data);
- else {
- dbp->err(dbp, ret, "DB->get");
- goto err;
- }
- if ((ret = dbp->del(dbp, NULL, &key, 0)) == 0)
- printf("db: %s: key was deleted.\n", (char *)key.data);
- else {
- dbp->err(dbp, ret, "DB->del");
- goto err;
- }
- After the DB->del call returns, the entry referenced by the key
-fruit has been removed from the database.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/errors.html b/bdb/docs/ref/simple_tut/errors.html
deleted file mode 100644
index bb7e8a67184..00000000000
--- a/bdb/docs/ref/simple_tut/errors.html
+++ /dev/null
@@ -1,46 +0,0 @@
-
-
-
-
-
- The Berkeley DB interfaces always return a value of 0 on success. If the
-operation does not succeed for any reason, the return value will be
-non-zero.
- If a system error occurred (e.g., Berkeley DB ran out of disk space, or
-permission to access a file was denied, or an illegal argument was
-specified to one of the interfaces), Berkeley DB returns an errno
-value. All of the possible values of errno are greater than
-0.
- If the operation didn't fail due to a system error, but wasn't
-successful either, Berkeley DB returns a special error value. For example,
-if you tried to retrieve the data item associated with the key
-fruit, and there was no such key/data pair in the database,
-Berkeley DB would return DB_NOTFOUND, a special error value that means
-the requested key does not appear in the database. All of the possible
-special error values are less than 0.
- Berkeley DB also offers programmatic support for displaying error return values.
-First, the db_strerror interface returns a pointer to the error
-message corresponding to any Berkeley DB error return, similar to the ANSI C
-strerror interface, but is able to handle both system error returns and
-Berkeley DB-specific return values.
- Second, there are two error functions, DB->err and DB->errx.
-These functions work like the ANSI C printf interface, taking a
-printf-style format string and argument list, and optionally appending
-the standard error string to a message constructed from the format string
-and other arguments.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/example.txt b/bdb/docs/ref/simple_tut/example.txt
deleted file mode 100644
index e610648d1c1..00000000000
--- a/bdb/docs/ref/simple_tut/example.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-#include
- The simplest way to retrieve elements from a database is the
-DB->get interface.
- The DB->get interface takes the same five arguments that the
-DB->put interface takes:
- Here's what the code to call DB->get looks like:
-
-#define DATABASE "access.db"
-
-int
-main()
-{
- DB *dbp;
- DBT key, data;
- int ret;
-
- if ((ret = db_create(&dbp, NULL, 0)) != 0) {
- fprintf(stderr, "db_create: %s\n", db_strerror(ret));
- exit (1);
- }
- if ((ret = dbp->open(
- dbp, DATABASE, NULL, DB_BTREE, DB_CREATE, 0664)) != 0) {
- dbp->err(dbp, ret, "%s", DATABASE);
- goto err;
- }
-
- memset(&key, 0, sizeof(key));
- memset(&data, 0, sizeof(data));
- key.data = "fruit";
- key.size = sizeof("fruit");
- data.data = "apple";
- data.size = sizeof("apple");
-
- if ((ret = dbp->put(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key stored.\n", (char *)key.data);
- else {
- dbp->err(dbp, ret, "DB->put");
- goto err;
- }
- if ((ret = dbp->get(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key retrieved: data was %s.\n",
- (char *)key.data, (char *)data.data);
- else {
- dbp->err(dbp, ret, "DB->get");
- goto err;
- }
- It is not usually necessary to clear the DBT structures passed
-to the Berkeley DB functions between calls. This is not always true, when
-some of the less commonly used flags for DBT structures are
-used. The DBT manual page specified the details of those cases.
- It is possible, of course, to distinguish between system errors and the
-key/data pair simply not existing in the database. There are three
-standard returns from DB->get:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/handles.html b/bdb/docs/ref/simple_tut/handles.html
deleted file mode 100644
index 2396a224ee9..00000000000
--- a/bdb/docs/ref/simple_tut/handles.html
+++ /dev/null
@@ -1,29 +0,0 @@
-
-
-
-
-
- With a few minor exceptions, Berkeley DB functionality is accessed by creating
-a structure and then calling functions that are fields in that structure.
-This is, of course, similar to object-oriented concepts, of instances and
-methods on them. For simplicity, we will often refer to these structure
-fields as methods of the handle.
- The manual pages will show these methods as C structure references. For
-example, the open-a-database method for a database handle is represented
-as DB->open.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/intro.html b/bdb/docs/ref/simple_tut/intro.html
deleted file mode 100644
index a9b6f648cf5..00000000000
--- a/bdb/docs/ref/simple_tut/intro.html
+++ /dev/null
@@ -1,40 +0,0 @@
-
-
-
-
-
- As an introduction to Berkeley DB, we will present a few Berkeley DB programming
-concepts, and then a simple database application.
- The programming concepts are:
- This database application will:
- The introduction will be presented using the programming language C. The
-complete source of the final version of the
-example program is included in the Berkeley DB distribution.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/keydata.html b/bdb/docs/ref/simple_tut/keydata.html
deleted file mode 100644
index 38d34aebc5a..00000000000
--- a/bdb/docs/ref/simple_tut/keydata.html
+++ /dev/null
@@ -1,48 +0,0 @@
-
-
-
-
-
- Berkeley DB uses key/data pairs to identify elements in the database.
-That is, in the general case, whenever you call a Berkeley DB interface,
-you present a key to identify the key/data pair on which you intend
-to operate.
- For example, you might store some key/data pairs as follows:
- In each case, the first element of the pair is the key, and the second is
-the data. To store the first of these key/data pairs into the database,
-you would call the Berkeley DB interface to store items, with fruit as
-the key, and apple as the data. At some future time, you could
-then retrieve the data item associated with fruit, and the Berkeley DB
-retrieval interface would return apple to you. While there are
-many variations and some subtleties, all accesses to data in Berkeley DB come
-down to key/data pairs.
- Both key and data items are stored in simple structures (called
-DBTs) that contain a reference to memory and a length, counted
-in bytes. (The name DBT is an acronym for database
-thang, chosen because nobody could think of a sensible name that wasn't
-already in use somewhere else.) Key and data items can be arbitrary
-binary data of practically any length, including 0 bytes. There is a
-single data item for each key item, by default, but databases can be
-configured to support multiple data items for each key item.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/open.html b/bdb/docs/ref/simple_tut/open.html
deleted file mode 100644
index 24df8a8e17f..00000000000
--- a/bdb/docs/ref/simple_tut/open.html
+++ /dev/null
@@ -1,90 +0,0 @@
-
-
-
-
-
- Opening a database is done in two steps: first, a DB handle is
-created using the Berkeley DB db_create interface, and then the
-actual database is opened using the DB->open function.
- The db_create interface takes three arguments:
- The DB->open interface takes five arguments:
- Here's what the code to create the handle and then call DB->open
-looks like:
-
-#define DATABASE "access.db"
-
-int
-main()
-{
- DB *dbp;
- int ret;
-
- if ((ret = db_create(&dbp, NULL, 0)) != 0) {
- fprintf(stderr, "db_create: %s\n", db_strerror(ret));
- exit (1);
- }
- if ((ret = dbp->open(
- dbp, DATABASE, NULL, DB_BTREE, DB_CREATE, 0664)) != 0) {
- dbp->err(dbp, ret, "%s", DATABASE);
- goto err;
- }
- If the call to db_create is successful, the variable dbp
-will contain a database handle that will be used to configure and access
-an underlying database.
- As you see, the program opens a database named access.db. The
-underlying database is a Btree. Because the DB_CREATE flag was
-specified, the file will be created if it does not already exist. The
-mode of any created files will be 0664 (i.e., readable and writeable by
-the owner and the group, and readable by everyone else).
- One additional function call is used in this code sample, DB->err.
-This method works like the ANSI C printf interface. The second argument
-is the error return from a Berkeley DB function, and the rest of the arguments
-are a printf-style format string and argument list. The error message
-associated with the error return will be appended to a message constructed
-from the format string and other arguments. In the above code, if the
-DB->open call were to fail, the message it would display would be
-something like
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/simple_tut/put.html b/bdb/docs/ref/simple_tut/put.html
deleted file mode 100644
index 8ecdfa6cabf..00000000000
--- a/bdb/docs/ref/simple_tut/put.html
+++ /dev/null
@@ -1,127 +0,0 @@
-
-
-
-
-
- The simplest way to add elements to a database is the DB->put
-interface.
- The DB->put interface takes five arguments:
- Here's what the code to call DB->put looks like:
-
-#define DATABASE "access.db"
-
-int
-main()
-{
- DB *dbp;
- DBT key, data;
- int ret;
-
- if ((ret = db_create(&dbp, NULL, 0)) != 0) {
- fprintf(stderr, "db_create: %s\n", db_strerror(ret));
- exit (1);
- }
- if ((ret = dbp->open(
- dbp, DATABASE, NULL, DB_BTREE, DB_CREATE, 0664)) != 0) {
- dbp->err(dbp, ret, "%s", DATABASE);
- goto err;
- }
- memset(&key, 0, sizeof(key));
- memset(&data, 0, sizeof(data));
- key.data = "fruit";
- key.size = sizeof("fruit");
- data.data = "apple";
- data.size = sizeof("apple");
-
- if ((ret = dbp->put(dbp, NULL, &key, &data, 0)) == 0)
- printf("db: %s: key stored.\n", (char *)key.data);
- else {
- dbp->err(dbp, ret, "DB->put");
- goto err;
- }
- The first thing to notice about this new code is that we clear the
-DBT structures that we're about to pass as arguments to Berkeley DB
-functions. This is very important, and being careful to do so will
-result in fewer errors in your programs. All Berkeley DB structures
-instantiated in the application and handed to Berkeley DB should be cleared
-before use, without exception. This is necessary so that future
-versions of Berkeley DB may add additional fields to the structures. If
-applications clear the structures before use, it will be possible for
-Berkeley DB to change those structures without requiring that the applications
-be rewritten to be aware of the changes.
- Notice also that we're storing the trailing nul byte found in the C
-strings "fruit" and "apple" in both the key and data
-items, that is, the trailing nul byte is part of the stored key, and
-therefore has to be specified in order to access the data item. There is
-no requirement to store the trailing nul byte, it simply makes it easier
-for us to display strings that we've stored in programming languages that
-use nul bytes to terminate strings.
- In many applications, it is important not to overwrite existing
-data. For example, we might not want to store the key/data pair
-fruit/apple if it already existed, e.g., if someone had
-previously stored the key/data pair fruit/cherry into the
-database.
- This is easily accomplished by adding the DB_NOOVERWRITE flag to
-the DB->put call:
- This flag causes the underlying database functions to not overwrite any
-previously existing key/data pair. (Note that the value of the previously
-existing data doesn't matter in this case. The only question is if a
-key/data pair already exists where the key matches the key that we are
-trying to store.)
- Specifying DB_NOOVERWRITE opens up the possibility of a new
-Berkeley DB return value from the DB->put function, DB_KEYEXIST,
-which means we were unable to add the key/data pair to the database
-because the key already existed in the database. While the above sample
-code simply displays a message in this case:
- The following code shows an explicit check for this possibility:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/tcl/error.html b/bdb/docs/ref/tcl/error.html
deleted file mode 100644
index 3d1de037d52..00000000000
--- a/bdb/docs/ref/tcl/error.html
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
-
-
-
- The Tcl interfaces to Berkeley DB generally return TCL_OK on success and throw
-a Tcl error on failure, using the appropriate Tcl interfaces to provide
-the user with an informative error message. There are some "expected"
-failures, however, for which no Tcl error will be thrown and for which
-Tcl commands will return TCL_OK. These failures include when a
-searched-for key is not found, a requested key/data pair was previously
-deleted, or a key/data pair cannot be written because the key already
-exists.
- These failures can be detected by searching the Berkeley DB error message that
-is returned. For example, to detect that an attempt to put a record into
-the database failed because the key already existed:
- To simplify parsing, it is recommended that the initial Berkeley DB error name
-be checked, e.g., DB_KEYEXIST in the above example. These values will
-not change in future releases of Berkeley DB to ensure that Tcl scripts are not
-broken by upgrading to new releases of Berkeley DB. There are currently only
-three such "expected" error returns. They are:
- Finally, in some cases, when a Berkeley DB error occurs Berkeley DB will output
-additional error information. By default, all Berkeley DB error messages will
-be prefixed with the created command in whose context the error occurred
-(e.g., "env0", "db2", etc.). There are several ways to capture and
-access this information.
- First, if Berkeley DB invokes the error callback function, the additional
-information will be placed in the error result returned from the
-command and in the errorInfo backtrace variable in Tcl.
- Also the two calls to open an environment and
-open a database take an option, -errfile filename, which sets an
-output file to which these additional error messages should be written.
- Additionally the two calls to open an environment and
-open a database take an option, -errpfx string, which sets the
-error prefix to the given string. This option may be useful
-in circumstances where a more descriptive prefix is desired or
-where a constant prefix indicating an error is desired.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/tcl/faq.html b/bdb/docs/ref/tcl/faq.html
deleted file mode 100644
index 29f63b42385..00000000000
--- a/bdb/docs/ref/tcl/faq.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- To compile the Tcl interface with a particular version of Tcl, use the
---with-tcl option to specify the Tcl installation directory that contains
-the tclConfig.sh file.
- See Changing compile or load options
-for more information.
- The Berkeley DB Tcl interface requires Tcl version 8.1 or greater. You can
-download a copy of Tcl from the
-Ajuba Solutions
-corporate web site.
- If the Tcl installation was moved after it was configured and installed,
-try re-configuring and re-installing Tcl.
- Also, some systems do not search for shared libraries by default, or do
-not search for shared libraries named the way the Tcl installation names
-them, or are searching for a different kind of library than those in
-your Tcl installation. For example, Linux systems often require linking
-"libtcl.a" to "libtcl#.#.a", while AIX systems often require adding the
-"-brtl" flag to the linker. A simpler solution that almost always works
-on all systems is to create a link from "libtcl.#.#.a" or "libtcl.so"
-(or whatever you happen to have) to "libtcl.a" and reconfigure.
- In some versions of Tcl, the "tclConfig.sh" autoconfiguration script
-created by the Tcl installation does not work properly under AIX. To
-build a working Berkeley DB Tcl API when this happens, use the "--enable-tcl"
-flag to configure Berkeley DB (rather than "--with-tcl"). In addition, you
-will have to specify any necessary include and library paths and linker
-flags needed to build with Tcl by setting the CPPFLAGS, LIBS and LDFLAGS
-environment variables before running configure.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/tcl/intro.html b/bdb/docs/ref/tcl/intro.html
deleted file mode 100644
index 6484eaac6b8..00000000000
--- a/bdb/docs/ref/tcl/intro.html
+++ /dev/null
@@ -1,70 +0,0 @@
-
-
-
-
-
- Berkeley DB includes a dynamically loadable Tcl API. The Tcl API requires that
-Tcl/Tk 8.1 or later already be installed on your system. We recommend
-that you install later releases of Tcl/Tk than 8.1, if possible,
-especially on Windows platforms, as we found that we had to make local
-fixes to the 8.1 release in a few cases. You can download a copy of
-Tcl from the Ajuba
-Solutions corporate web site.
- This document assumes that you have already configured Berkeley DB for Tcl
-support and you have built and installed everything where you want it
-to be. If you have not done so, see
-Configuring Berkeley DB or
-Building for Win32 for more
-information.
- Once enabled, the Berkeley DB shared library for Tcl is automatically installed
-as part of the standard installation process. However, if you wish to be
-able to dynamically load it as a Tcl package into your script there are
-several steps that must be performed:
- For example:
- Note that your Tcl and Berkeley DB version numbers may differ from the example,
-and so your tclsh and and library names may be different.
- The Berkeley DB package may be loaded into the user's interactive Tcl script
-(or wish session) via the "load" command. For example:
- Note that your Berkeley DB version numbers may differ from the example, and so
-the library name may be different.
- If you installed your library to run as a Tcl package, Tcl application
-scripts should use the "package" command to indicate to the Tcl
-interpreter that it needs the Berkeley DB package and where to find it. For
-example:
- No matter which way the library gets loaded, it creates a command named
-berkdb. All of the Berkeley DB functionality is accessed via this
-command and additional commands it creates on behalf of the application.
-A simple test to determine if everything is loaded and ready is to ask
-for the version:
- This should return you the Berkeley DB version in a string format.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/tcl/program.html b/bdb/docs/ref/tcl/program.html
deleted file mode 100644
index 881c8848bac..00000000000
--- a/bdb/docs/ref/tcl/program.html
+++ /dev/null
@@ -1,33 +0,0 @@
-
-
-
-
-
- The Tcl API closely parallels the Berkeley DB programmatic interfaces. If you
-are already familiar with one of those interfaces there will not be many
-surprises in the Tcl API.
- Several pieces of Berkeley DB functionality are not available in the Tcl API.
-Any of the functions that require a user-provided function are not
-supported via the Tcl API. For example, there is no equivalent to the
-DB->set_dup_compare or the DBENV->set_errcall
-methods.
- The Berkeley DB Tcl API always turns on the DB_THREAD flag for environments and
-databases making no assumptions about the existence or lack thereof of
-threads support in current or future releases of Tcl.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/tcl/using.html b/bdb/docs/ref/tcl/using.html
deleted file mode 100644
index 6c927477c2c..00000000000
--- a/bdb/docs/ref/tcl/using.html
+++ /dev/null
@@ -1,53 +0,0 @@
-
-
-
-
-
- All commands in the Berkeley DB Tcl interface are of the form:
- The command handle is berkdb or one of the additional
-commands that may be created. The operation is what you want
-to do to that handle and the options apply to the operation.
-Commands that get created on behalf of the application have their own sets
-of operations. Generally any calls in DB that result in new object
-handles will translate into a new command handle in Tcl. Then the user
-can access the operations of the handle via the new Tcl command handle.
- Newly created commands are named with an abbreviated form of their objects
-followed by a number. Some created commands are subcommands of other
-created commands and will be the first command, followed by a period, '.'
-followed by the new subcommand. For example, suppose you have a database
-already existing called my_data.db. The following example shows the
-commands created when you open the database, and when you open a cursor:
- All commands in the library support a special option -? that will
-list the correct operations for a command or the correct options.
- A list of commands and operations can be found in the
-Tcl Interface documentation.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/test/faq.html b/bdb/docs/ref/test/faq.html
deleted file mode 100644
index ec5d2d3f061..00000000000
--- a/bdb/docs/ref/test/faq.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-
-
-
- The test suite an take anywhere from some number of hours to several
-days to run, depending on your hardware configuration. As long as the
-run is making forward progress and new lines are being written to the
-ALL.OUT file, everything is probably fine.
- The test suite requires Tcl 8.1 or greater, preferably at least Tcl 8.3.
-If you are using an earlier version of Tcl, the test suite may simply
-hang at some point.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/test/run.html b/bdb/docs/ref/test/run.html
deleted file mode 100644
index 078951a05ea..00000000000
--- a/bdb/docs/ref/test/run.html
+++ /dev/null
@@ -1,78 +0,0 @@
-
-
-
-
-
- Once you have started tclsh and have loaded the test.tcl source file (see
-Running the test suite under UNIX
-and Running the test suite under
-Windows for more information), you are ready to run the test suite. At
-the tclsh prompt, to run the entire test suite, enter:
- Running all the tests can take from several hours to a few days to
-complete, depending on your hardware. For this reason, the output from
-this command is re-directed to a file in the current directory named
-ALL.OUT. Periodically, a line will be written to the standard
-output indicating what test is being run. When the suite has finished,
-a single message indicating that the test suite completed successfully or
-that it failed will be written. If the run failed, you should review the
-file ALL.OUT to determine which tests failed. Any errors will appear in
-that file as output lines beginning with the string: FAIL.
- It is also possible to run specific tests or tests for a particular
-subsystem:
- Or to run a single, individual test:
- It is also possible to modify the test run based on arguments on the
-command line. For example, the command:
- will run a greatly abbreviated form of test001, doing 10 operations
-instead of 10,000.
- In all cases, when not running the entire test suite as described above,
-a successful test run will return you to the tclsh prompt (%). On
-failure, a message is displayed indicating what failed.
- Tests are run, by default, in the directory TESTDIR. However,
-the test files are often very large. To use a different directory for
-the test directory, edit the file include.tcl in your build directory,
-and change the line:
- to a more appropriate value for your system, e.g.:
- Alternatively, you can create a symbolic link named TESTDIR in your build
-directory to an appropriate location for running the tests. Regardless
-of where you run the tests, the TESTDIR directory should be on a local
-filesystem, using a remote filesystem (e.g., NFS) will almost certainly
-cause spurious test failures.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/toc.html b/bdb/docs/ref/toc.html
deleted file mode 100644
index e56ee5d4859..00000000000
--- a/bdb/docs/ref/toc.html
+++ /dev/null
@@ -1,310 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/admin.html b/bdb/docs/ref/transapp/admin.html
deleted file mode 100644
index c908a7a33a2..00000000000
--- a/bdb/docs/ref/transapp/admin.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
-
- When building transactional applications, it is usually necessary to
-build an administrative infrastructure around the database environment.
-There are five components to this infrastructure, and each is
-supported by the Berkeley DB package in two different ways: a standalone
-utility and one or more library interfaces.
- When writing multi-threaded server applications and/or applications
-intended for download from the web, it is usually simpler to create
-local threads that are responsible for administration of the database
-environment as scheduling is often simpler in a single-process model,
-and only a single binary need be installed and run. However, the
-supplied utilities can be generally useful tools even when the
-application is responsible for doing its own administration, as
-applications rarely offer external interfaces to database
-administration. The utilities are required when programming to a Berkeley DB
-scripting interface, as the scripting APIs do not always offer
-interfaces to the administrative functionality.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/app.html b/bdb/docs/ref/transapp/app.html
deleted file mode 100644
index 3c946989b50..00000000000
--- a/bdb/docs/ref/transapp/app.html
+++ /dev/null
@@ -1,117 +0,0 @@
-
-
-
-
-
- When building transactionally protected applications, there are some
-special issues that must be considered. The most important one is that,
-if any thread of control exits for any reason while holding Berkeley DB
-resources, recovery must be performed to:
- Complicating this problem is the fact that the Berkeley DB library itself
-cannot determine if recovery is required, the application itself
-must make that decision. A further complication is that
-recovery must be single-threaded, that is, one thread of control or
-process must perform recovery before any other thread of control or
-processes attempts to create or join the Berkeley DB environment.
- There are two approaches to handling this problem:
- Requirements for shutting down the environment cleanly differ depending
-on the type of environment created. If the environment is public and
-persistent (i.e., the DB_PRIVATE flag was not specified to the
-DBENV->open function), recovery must be performed if any transaction was
-not committed or aborted, or DBENV->close function was not called for
-any open DB_ENV handle.
- If the environment is private and temporary (i.e., the DB_PRIVATE
-flag was specified to the DBENV->open function), recovery must be performed
-if any transaction was not committed or aborted, or DBENV->close function
-was not called for any open DB_ENV handle. In addition, at least
-one transaction checkpoint must be performed after all existing
-transactions have been committed or aborted.
- There are two common ways to build transactionally protected Berkeley DB
-applications. The most common way is as a single, usually
-multi-threaded, process. This architecture is simplest because it
-requires no monitoring of other threads of control. When the
-application starts, it opens and potentially creates the environment,
-runs recovery (whether it was needed or not), and then opens its
-databases. From then on, the application can create new threads of
-control as it chooses. All threads of control share the open Berkeley DB
-DB_ENV and DB handles. In this model, databases are
-rarely opened or closed when more than a single thread of control is
-running, that is, they are opened when only a single thread is running,
-and closed after all threads but one have exited. The last thread of
-control to exit closes the databases and the environment.
- An alternative way to build Berkeley DB applications is as a set of
-cooperating processes, which may or may not be multi-threaded. This
-architecture is more complicated.
- First, this architecture requires that the order in which threads of
-control are created and subsequently access the Berkeley DB environment be
-controlled, because recovery must be single-threaded. The first thread
-of control to access the environment must run recovery, and no other
-thread should attempt to access the environment until recovery is
-complete. (Note that this ordering requirement does not apply to
-environment creation without recovery. If multiple threads attempt to
-create a Berkeley DB environment, only one will perform the creation and the
-others will join the already existing environment.)
- Second, this architecture requires that threads of control be monitored.
-If any thread of control that owns Berkeley DB resources exits, without first
-cleanly discarding those resources, recovery is usually necessary.
-Before running recovery, all threads using the Berkeley DB environment must
-relinquish all of their Berkeley DB resources (it does not matter if they do
-so gracefully or because they are forced to exit). Then recovery can
-be run and the threads of control continued or re-started.
- We have found that the safest way to structure groups of cooperating
-processes is to first create a single process (often a shell script)
-that opens/creates the Berkeley DB environment and runs recovery, and which
-then creates the processes or threads that will actually perform work.
-The initial thread has no further responsibilities other than to monitor
-the threads of control it has created, to ensure that none of them
-unexpectedly exits. If one exits, the initial process then forces all
-of the threads of control using the Berkeley DB environment to exit, runs
-recovery, and restarts the working threads of control.
- If it is not practical to have a single parent for the processes sharing
-a Berkeley DB environment, each process sharing the environment should log
-their connection to and exit from the environment in some fashion that
-permits a monitoring process to detect if a thread of control may have
-potentially acquired Berkeley DB resources and never released them.
- Obviously, it is important that the monitoring process in either case
-be as simple and well-tested as possible as there is no recourse should
-it fail.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/archival.html b/bdb/docs/ref/transapp/archival.html
deleted file mode 100644
index 2e88158504d..00000000000
--- a/bdb/docs/ref/transapp/archival.html
+++ /dev/null
@@ -1,149 +0,0 @@
-
-
-
-
-
- The third component of the administrative infrastructure, archival for
-catastrophic recovery, concerns the recoverability of the database in
-the face of catastrophic failure. Recovery after catastrophic failure
-is intended to minimize data loss when physical hardware has been
-destroyed, for example, loss of a disk that contains databases or log
-files. While the application may still experience data loss in this
-case, it is possible to minimize it.
- First, you may want to periodically create snapshots (i.e., backups) of
-your databases to make it possible to recover from catastrophic failure.
-These snapshots are either a standard backup which creates a consistent
-picture of the databases as of a single instant in time, or an on-line
-backup (also known as a hot backup), which creates a
-consistent picture of the databases as of an unspecified instant during
-the period of time when the snapshot was made. The advantage of a hot
-backup is that applications may continue to read and write the databases
-while the snapshot is being taken. The disadvantage of a hot backup is
-that more information must be archived, and recovery based on a hot
-backup is to an unspecified time between the start of the backup and
-when the backup is completed.
- Second, after taking a snapshot, you should periodically archive the
-log files being created in the environment. It is often helpful to
-think of database archival in terms of full and incremental filesystem
-backups. A snapshot is a full backup, while the periodic archival of
-the current log files is an incremental. For example, it might be
-reasonable to take a full snapshot of a database environment weekly or
-monthly, and then archive additional log files daily. Using both the
-snapshot and the log files, a catastrophic crash at any time can be
-recovered to the time of the most recent log archival, a time long after
-the original snapshot.
- To create a standard backup of your database that can be used to recover
-from catastrophic failure, take the following steps:
- If the database files are stored in a separate directory from the other
-Berkeley DB files, it may be simpler to archive the directory itself instead
-of the individual files (see DBENV->set_data_dir for additional
-information). If you are performing a hot backup, the utility you use
-to copy the files must read database pages atomically (as described by
-Berkeley DB recoverability).
- Note: if any of the database files did not have an open DB
-handle during the lifetime of the current log files, db_archive
-will not list them in its output! For this reason, it may be simpler
-to use a separate database file directory, and archive the entire
-directory instead of only the files listed by db_archive.
- To create a hot backup of your database that can be used to
-recover from catastrophic failure, take the following steps:
- To archive your log files, run the db_archive utility, using
-the -l option, to identify all of the database log files, and
-copy them to your backup media. If the database log files are stored
-in a separate directory from the other database files, it may be simpler
-to archive the directory itself instead of the individual files (see
-the DBENV->set_lg_dir function for more information).
- Once these steps are completed, your database can be recovered from
-catastrophic failure (see Recovery procedures for
-more information).
- To update your snapshot so that recovery from catastrophic failure is
-possible up to a new point in time, repeat step #2 under the hot backup
-instructions, copying all existing log files to a backup device. This
-is applicable to both standard and hot backups, that is, you can update
-snapshots made in either way. Each time both the database and log files
-are copied to backup media, you may discard all previous database
-snapshots and saved log files. Archiving additional log files does not
-allow you to discard either previous database snapshots or log files.
- The time to restore from catastrophic failure is a function of the
-number of log records that have been written since the snapshot was
-originally created. Perhaps more importantly, the more separate pieces
-of backup media you use, the more likely that you will have a problem
-reading from one of them. For these reasons, it is often best to make
-snapshots on a regular basis.
- For archival safety, ensure that you have multiple copies of your
-database backups, verify that your archival media is error-free and
-readable, and that copies of your backups are stored off-site!
- The functionality provided by the db_archive utility is also
-available directly from the Berkeley DB library. The following code fragment
-prints out a list of log and database files that need to be archived.
-
- /* Get the list of database files. */
- if ((ret = log_archive(dbenv,
- &list, DB_ARCH_ABS | DB_ARCH_DATA, NULL)) != 0) {
- dbenv->err(dbenv, ret, "log_archive: DB_ARCH_DATA");
- exit (1);
- }
- if (list != NULL) {
- for (begin = list; *list != NULL; ++list)
- printf("database file: %s\n", *list);
- free (begin);
- }
-
- /* Get the list of log files. */
- if ((ret = log_archive(dbenv,
- &list, DB_ARCH_ABS | DB_ARCH_LOG, NULL)) != 0) {
- dbenv->err(dbenv, ret, "log_archive: DB_ARCH_LOG");
- exit (1);
- }
- if (list != NULL) {
- for (begin = list; *list != NULL; ++list)
- printf("log file: %s\n", *list);
- free (begin);
- }
-} Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/checkpoint.html b/bdb/docs/ref/transapp/checkpoint.html
deleted file mode 100644
index b9bd81a3ed6..00000000000
--- a/bdb/docs/ref/transapp/checkpoint.html
+++ /dev/null
@@ -1,127 +0,0 @@
-
-
-
-
-
- The second component of the infrastructure is performing checkpoints of
-the log files. As transactions commit, change records are written into
-the log files, but the actual changes to the database are not
-necessarily written to disk. When a checkpoint is performed, the
-changes to the database that are part of committed transactions are
-written into the backing database file.
- Performing checkpoints is necessary for two reasons. First, you can
-only remove the Berkeley DB log files from your system after a checkpoint.
-Second, the frequency of your checkpoints is inversely proportional to
-the amount of time it takes to run database recovery after a system or
-application failure.
- Once the database pages are written, log files can be archived and removed
-from the system because they will never be needed for anything other than
-catastrophic failure. In addition, recovery after system or application
-failure only has to redo or undo changes since the last checkpoint, since
-changes before the checkpoint have all been flushed to the filesystem.
- Berkeley DB provides a separate utility, db_checkpoint, which can be
-used to perform checkpoints. Alternatively, applications can write
-their own checkpoint utility using the underlying txn_checkpoint
-function. The following code fragment checkpoints the database
-environment every 60 seconds:
-
- while ((ch = getopt(argc, argv, "")) != EOF)
- switch (ch) {
- case '?':
- default:
- usage();
- }
- argc -= optind;
- argv += optind;
-
- env_dir_create();
- env_open(&dbenv);
-
- /* Start a checkpoint thread. */
- if ((errno = pthread_create(
- &ptid, NULL, checkpoint_thread, (void *)dbenv)) != 0) {
- fprintf(stderr,
- "txnapp: failed spawning checkpoint thread: %s\n",
- strerror(errno));
- exit (1);
- }
-
- /* Open database: Key is fruit class; Data is specific type. */
- db_open(dbenv, &db_fruit, "fruit", 0);
-
- /* Open database: Key is a color; Data is an integer. */
- db_open(dbenv, &db_color, "color", 0);
-
- /*
- * Open database:
- * Key is a name; Data is: company name, address, cat breeds.
- */
- db_open(dbenv, &db_cats, "cats", 1);
-
- add_fruit(dbenv, db_fruit, "apple", "yellow delicious");
-
- add_color(dbenv, db_color, "blue", 0);
- add_color(dbenv, db_color, "blue", 3);
-
- add_cat(dbenv, db_cats,
- "Amy Adams",
- "Sleepycat Software",
- "394 E. Riding Dr., Carlisle, MA 01741, USA",
- "abyssinian",
- "bengal",
- "chartreaux",
- NULL);
-
- return (0);
-}
-
-void *
-checkpoint_thread(void *arg)
-{
- DB_ENV *dbenv;
- int ret;
-
- dbenv = arg;
- dbenv->errx(dbenv, "Checkpoint thread: %lu", (u_long)pthread_self());
-
- /* Checkpoint once a minute. */
- for (;; sleep(60))
- switch (ret = txn_checkpoint(dbenv, 0, 0, 0)) {
- case 0:
- case DB_INCOMPLETE:
- break;
- default:
- dbenv->err(dbenv, ret, "checkpoint thread");
- exit (1);
- }
-
- /* NOTREACHED */
-} As checkpoints can be quite expensive, choosing how often to perform a
-checkpoint is a common tuning parameter for Berkeley DB applications.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/cursor.html b/bdb/docs/ref/transapp/cursor.html
deleted file mode 100644
index bb1aff98a8c..00000000000
--- a/bdb/docs/ref/transapp/cursor.html
+++ /dev/null
@@ -1,169 +0,0 @@
-
-
-
-
-
- Berkeley DB cursors may be used inside a transaction, exactly like any other
-DB method. The enclosing transaction ID must be specified when
-the cursor is created, but it does not then need to be further specified
-on operations performed using the cursor. One important point to
-remember is that a cursor must be closed before the enclosing
-transaction is committed or aborted.
- The following code fragment uses a cursor to store a new key in the cats
-database with four associated data items. The key is a name. The data
-items are a company name, an address, and a list of the breeds of cat
-owned. Each of the data entries is stored as a duplicate data item.
-In this example, transactions are necessary to ensure that either all or none
-of the data items appear in case of system or application failure.
-
- while ((ch = getopt(argc, argv, "")) != EOF)
- switch (ch) {
- case '?':
- default:
- usage();
- }
- argc -= optind;
- argv += optind;
-
- env_dir_create();
- env_open(&dbenv);
-
- /* Open database: Key is fruit class; Data is specific type. */
- db_open(dbenv, &db_fruit, "fruit", 0);
-
- /* Open database: Key is a color; Data is an integer. */
- db_open(dbenv, &db_color, "color", 0);
-
- /*
- * Open database:
- * Key is a name; Data is: company name, address, cat breeds.
- */
- db_open(dbenv, &db_cats, "cats", 1);
-
- add_fruit(dbenv, db_fruit, "apple", "yellow delicious");
-
- add_color(dbenv, db_color, "blue", 0);
- add_color(dbenv, db_color, "blue", 3);
-
- add_cat(dbenv, db_cats,
- "Amy Adams",
- "Sleepycat Software",
- "394 E. Riding Dr., Carlisle, MA 01741, USA",
- "abyssinian",
- "bengal",
- "chartreaux",
- NULL);
-
- return (0);
-}
-
-void
-add_cat(DB_ENV *dbenv, DB *db, char *name, ...)
-{
- va_list ap;
- DBC *dbc;
- DBT key, data;
- DB_TXN *tid;
- int ret;
- char *s;
-
- /* Initialization. */
- memset(&key, 0, sizeof(key));
- memset(&data, 0, sizeof(data));
- key.data = name;
- key.size = strlen(name);
-
-retry: /* Begin the transaction. */
- if ((ret = txn_begin(dbenv, NULL, &tid, 0)) != 0) {
- dbenv->err(dbenv, ret, "txn_begin");
- exit (1);
- }
-
- /* Delete any previously existing item. */
- switch (ret = db->del(db, tid, &key, 0)) {
- case 0:
- case DB_NOTFOUND:
- break;
- case DB_LOCK_DEADLOCK:
- /* Deadlock: retry the operation. */
- if ((ret = txn_abort(tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_abort");
- exit (1);
- }
- goto retry;
- default:
- dbenv->err(dbenv, ret, "db->del: %s", name);
- exit (1);
- }
-
- /* Create a cursor. */
- if ((ret = db->cursor(db, tid, &dbc, 0)) != 0) {
- dbenv->err(dbenv, ret, "db->cursor");
- exit (1);
- }
-
- /* Append the items, in order. */
- va_start(ap, name);
- while ((s = va_arg(ap, char *)) != NULL) {
- data.data = s;
- data.size = strlen(s);
- switch (ret = dbc->c_put(dbc, &key, &data, DB_KEYLAST)) {
- case 0:
- break;
- case DB_LOCK_DEADLOCK:
- va_end(ap);
-
- /* Deadlock: retry the operation. */
- if ((ret = dbc->c_close(dbc)) != 0) {
- dbenv->err(
- dbenv, ret, "dbc->c_close");
- exit (1);
- }
- if ((ret = txn_abort(tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_abort");
- exit (1);
- }
- goto retry;
- default:
- /* Error: run recovery. */
- dbenv->err(dbenv, ret, "dbc->put: %s/%s", name, s);
- exit (1);
- }
- }
- va_end(ap);
-
- /* Success: commit the change. */
- if ((ret = dbc->c_close(dbc)) != 0) {
- dbenv->err(dbenv, ret, "dbc->c_close");
- exit (1);
- }
- if ((ret = txn_commit(tid, 0)) != 0) {
- dbenv->err(dbenv, ret, "txn_commit");
- exit (1);
- }
-} Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/data_open.html b/bdb/docs/ref/transapp/data_open.html
deleted file mode 100644
index 904778c3558..00000000000
--- a/bdb/docs/ref/transapp/data_open.html
+++ /dev/null
@@ -1,119 +0,0 @@
-
-
-
-
-
- Next, we open three databases ("color" and "fruit" and "cats"), in the
-database environment. Again, our DB database handles are
-declared to be free-threaded using the DB_THREAD flag, and so
-may be used by any number of threads we subsequently create.
-
- while ((ch = getopt(argc, argv, "")) != EOF)
- switch (ch) {
- case '?':
- default:
- usage();
- }
- argc -= optind;
- argv += optind;
-
- env_dir_create();
- env_open(&dbenv);
-
- /* Open database: Key is fruit class; Data is specific type. */
- db_open(dbenv, &db_fruit, "fruit", 0);
-
- /* Open database: Key is a color; Data is an integer. */
- db_open(dbenv, &db_color, "color", 0);
-
- /*
- * Open database:
- * Key is a name; Data is: company name, address, cat breeds.
- */
- db_open(dbenv, &db_cats, "cats", 1);
-
- return (0);
-}
-
-void
-db_open(DB_ENV *dbenv, DB **dbp, char *name, int dups)
-{
- DB *db;
- int ret;
-
- /* Create the database handle. */
- if ((ret = db_create(&db, dbenv, 0)) != 0) {
- dbenv->err(dbenv, ret, "db_create");
- exit (1);
- }
-
- /* Optionally, turn on duplicate data items. */
- if (dups && (ret = db->set_flags(db, DB_DUP)) != 0) {
- dbenv->err(dbenv, ret, "db->set_flags: DB_DUP");
- exit (1);
- }
-
- /*
- * Open a database in the environment:
- * create if it doesn't exist
- * free-threaded handle
- * read/write owner only
- */
- if ((ret = db->open(db, name, NULL,
- DB_BTREE, DB_CREATE | DB_THREAD, S_IRUSR | S_IWUSR)) != 0) {
- dbenv->err(dbenv, ret, "db->open: %s", name);
- exit (1);
- }
-
- *dbp = db;
-} There is no reason to wrap database opens inside of transactions. All
-database opens are transaction protected internally to Berkeley DB, and
-applications using transaction-protected environments can simply rely on
-files either being successfully re-created in a recovered environment,
-or not appearing at all.
- After running this initial code, we can use the db_stat utility
-to display information about a database we have created:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/deadlock.html b/bdb/docs/ref/transapp/deadlock.html
deleted file mode 100644
index 65765ec5903..00000000000
--- a/bdb/docs/ref/transapp/deadlock.html
+++ /dev/null
@@ -1,92 +0,0 @@
-
-
-
-
-
- The first component of the infrastructure, deadlock detection, is not
-so much a requirement specific to transaction protected applications,
-but rather is necessary for almost all applications where more than a
-single thread of control will be accessing the database at one time.
-While Berkeley DB automatically handles database locking, it is normally
-possible for deadlock to occur. It is not required by all transactional
-applications, but exceptions are rare.
- When the deadlock occurs, two (or more) threads of control each request
-additional locks which can never be granted because one of the threads
-of control waiting holds the requested resource.
- For example, consider two processes A and B. Let's say that A obtains
-an exclusive lock on item X, and B obtains an exclusive lock on item Y.
-Then, A requests a lock on Y and B requests a lock on X. A will wait
-until resource Y becomes available and B will wait until resource X
-becomes available. Unfortunately, since both A and B are waiting,
-neither will release the locks they hold and neither will ever obtain
-the resource on which it is waiting. In order to detect that deadlock
-has happened, a separate process or thread must review the locks
-currently held in the database. If deadlock has occurred, a victim must
-be selected, and that victim will then return the error
-DB_LOCK_DEADLOCK from whatever Berkeley DB call it was making.
- Berkeley DB provides a separate UNIX-style utility which can be used to
-perform this deadlock detection, named db_deadlock.
-Alternatively, applications can create their own deadlock utility or
-thread using the underlying lock_detect function, or specify
-that Berkeley DB run the deadlock detector internally whenever there is a
-conflict over a lock (see DBENV->set_lk_detect for more
-information). The following code fragment does the latter:
-
- /* Create the environment handle. */
- if ((ret = db_env_create(&dbenv, 0)) != 0) {
- fprintf(stderr,
- "txnapp: db_env_create: %s\n", db_strerror(ret));
- exit (1);
- }
-
- /* Set up error handling. */
- dbenv->set_errpfx(dbenv, "txnapp");
-
- /* Do deadlock detection internally. */
- if ((ret = dbenv->set_lk_detect(dbenv, DB_LOCK_DEFAULT)) != 0) {
- dbenv->err(dbenv, ret, "set_lk_detect: DB_LOCK_DEFAULT");
- exit (1);
- }
-
- /*
- * Open a transactional environment:
- * create if it doesn't exist
- * free-threaded handle
- * run recovery
- * read/write owner only
- */
- if ((ret = dbenv->open(dbenv, ENV_DIRECTORY,
- DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG |
- DB_INIT_MPOOL | DB_INIT_TXN | DB_RECOVER | DB_THREAD,
- S_IRUSR | S_IWUSR)) != 0) {
- dbenv->err(dbenv, ret, "dbenv->open: %s", ENV_DIRECTORY);
- exit (1);
- }
-
- *dbenvp = dbenv;
-} Deciding how often to run the deadlock detector and which of the
-deadlocked transactions will be forced to abort when the deadlock is
-detected is a common tuning parameter for Berkeley DB applications.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/env_open.html b/bdb/docs/ref/transapp/env_open.html
deleted file mode 100644
index 7209a3fef5f..00000000000
--- a/bdb/docs/ref/transapp/env_open.html
+++ /dev/null
@@ -1,174 +0,0 @@
-
-
-
-
-
- Creating transaction-protected applications using the Berkeley DB library is
-quite easy. Applications first use DBENV->open to initialize
-the database environment. Transaction-protected applications normally
-require all four Berkeley DB subsystems, so the DB_INIT_MPOOL,
-DB_INIT_LOCK, DB_INIT_LOG and DB_INIT_TXN flags
-should be specified.
- Once the application has called DBENV->open, it opens its
-databases within the environment. Once the databases are opened, the
-application makes changes to the databases inside of transactions. Each
-set of changes that entail a unit of work should be surrounded by the
-appropriate txn_begin, txn_commit and txn_abort
-calls. The Berkeley DB access methods will make the appropriate calls into
-the lock, log and memory pool subsystems in order to guarantee
-transaction semantics. When the application is ready to exit, all
-outstanding transactions should have been committed or aborted.
- Databases accessed by a transaction must not be closed during the
-transaction. Once all outstanding transactions are finished, all open
-Berkeley DB files should be closed. When the Berkeley DB database files have been
-closed, the environment should be closed by calling DBENV->close.
- The following code fragment creates the database environment directory,
-then opens the environment, running recovery. Our DB_ENV
-database environment handle is declared to be free-threaded using the
-DB_THREAD flag, and so may be used by any number of threads that
-we may subsequently create.
-
-#include <errno.h>
-#include <pthread.h>
-#include <stdarg.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <db.h>
-
-#define ENV_DIRECTORY "TXNAPP"
-
-void env_dir_create(void);
-void env_open(DB_ENV **);
-
-int
-main(int argc, char *argv)
-{
- extern char *optarg;
- extern int optind;
- DB *db_cats, *db_color, *db_fruit;
- DB_ENV *dbenv;
- pthread_t ptid;
- int ch;
-
- while ((ch = getopt(argc, argv, "")) != EOF)
- switch (ch) {
- case '?':
- default:
- usage();
- }
- argc -= optind;
- argv += optind;
-
- env_dir_create();
- env_open(&dbenv);
-
- return (0);
-}
-
-void
-env_dir_create()
-{
- struct stat sb;
-
- /*
- * If the directory exists, we're done. We do not further check
- * the type of the file, DB will fail appropriately if it's the
- * wrong type.
- */
- if (stat(ENV_DIRECTORY, &sb) == 0)
- return;
-
- /* Create the directory, read/write/access owner only. */
- if (mkdir(ENV_DIRECTORY, S_IRWXU) != 0) {
- fprintf(stderr,
- "txnapp: mkdir: %s: %s\n", ENV_DIRECTORY, strerror(errno));
- exit (1);
- }
-}
-
-void
-env_open(DB_ENV **dbenvp)
-{
- DB_ENV *dbenv;
- int ret;
-
- /* Create the environment handle. */
- if ((ret = db_env_create(&dbenv, 0)) != 0) {
- fprintf(stderr,
- "txnapp: db_env_create: %s\n", db_strerror(ret));
- exit (1);
- }
-
- /* Set up error handling. */
- dbenv->set_errpfx(dbenv, "txnapp");
-
- /*
- * Open a transactional environment:
- * create if it doesn't exist
- * free-threaded handle
- * run recovery
- * read/write owner only
- */
- if ((ret = dbenv->open(dbenv, ENV_DIRECTORY,
- DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG |
- DB_INIT_MPOOL | DB_INIT_TXN | DB_RECOVER | DB_THREAD,
- S_IRUSR | S_IWUSR)) != 0) {
- dbenv->err(dbenv, ret, "dbenv->open: %s", ENV_DIRECTORY);
- exit (1);
- }
-
- *dbenvp = dbenv;
-} After running this initial program, we can use the db_stat
-utility to display the contents of the environment directory:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/filesys.html b/bdb/docs/ref/transapp/filesys.html
deleted file mode 100644
index fc68089e90f..00000000000
--- a/bdb/docs/ref/transapp/filesys.html
+++ /dev/null
@@ -1,62 +0,0 @@
-
-
-
-
-
- When running in a transaction-protected environment, database creation
-and deletion are logged as stand-alone transactions internal to Berkeley DB.
-That is, for each such operation a new transaction is begun and aborted
-or committed internally, so that they will be recovered during recovery.
- The Berkeley DB API supports removing and renaming files. Renaming files is
-supported by the DB->rename method, and removing files by the
-DB->remove method. Berkeley DB does not permit specifying the
-DB_TRUNCATE flag when opening a file in a transaction protected
-environment. This is an implicit file deletion, but one that does not
-always require the same operating system file permissions as does deleting
-and creating a file.
- If you have changed the name of a file or deleted it outside of the Berkeley DB
-library (e.g., you explicitly removed a file using your normal operating
-system utilities), then it is possible that recovery will not be able to
-find a database referenced in the log. In this case, db_recover
-will produce a warning message saying it was unable to locate a file it
-expected to find. This message is only a warning, as the file may have
-been subsequently deleted as part of normal database operations before
-the failure occurred, and so is not necessarily a problem.
- Generally, any filesystem operations that are performed outside the Berkeley DB
-interface should be performed at the same time as making a snapshot of
-the database. To perform filesystem operations correctly:
- To shutdown database operations cleanly, all applications accessing the
-database environment must be shutdown and a transaction checkpoint must
-be taken. If the applications are not implemented such that they can be
-shutdown gracefully (i.e., closing all references to the database
-environment), recovery must be performed after all applications have been
-killed to ensure that the underlying databases are consistent on disk.
- While this step is not strictly necessary, it is strongly recommended.
-If this step is not performed, recovery from catastrophic failure will
-require that recovery first be performed up to the time of the
-filesystem operations, the filesystem operations be redone, and then
-recovery be performed from the filesystem operations forward.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/inc.html b/bdb/docs/ref/transapp/inc.html
deleted file mode 100644
index 35cf67d7efa..00000000000
--- a/bdb/docs/ref/transapp/inc.html
+++ /dev/null
@@ -1,201 +0,0 @@
-
-
-
-
-
- The third reason listed for using transactions was atomicity. Consider
-an application suite where multiple threads of control (multiple
-processes or threads in one or more processes) are changing the values
-associated with a key in one or more databases. Specifically, they are
-taking the current value, incrementing it, and then storing it back into
-the database.
- Such an application requires atomicity. Since we want to change a value
-in the database, we must make sure that once we read it, no other thread
-of control modifies it. For example, assume that both thread #1 and
-thread #2 are doing similar operations in the database, where thread #1
-is incrementing records by 3, and thread #2 is incrementing records by
-5. We want to increment the record by a total of 8. If the operations
-interleave in the right (well, wrong) order, that is not what will
-happen:
- As you can see, instead of incrementing the record by a total of 8,
-we've only incremented it by 3, because thread #1 overwrote thread #2's
-change. By wrapping the operations in transactions, we ensure that this
-cannot happen. In a transaction, when the first thread reads the
-record, locks are acquired that will not be released until the
-transaction finishes, guaranteeing that all other readers and writers
-will block, waiting for the first thread's transaction to complete (or
-to be aborted).
- Here is an example function that does transaction-protected increments
-on database records to ensure atomicity.
-
- while ((ch = getopt(argc, argv, "")) != EOF)
- switch (ch) {
- case '?':
- default:
- usage();
- }
- argc -= optind;
- argv += optind;
-
- env_dir_create();
- env_open(&dbenv);
-
- /* Open database: Key is fruit class; Data is specific type. */
- db_open(dbenv, &db_fruit, "fruit", 0);
-
- /* Open database: Key is a color; Data is an integer. */
- db_open(dbenv, &db_color, "color", 0);
-
- /*
- * Open database:
- * Key is a name; Data is: company name, address, cat breeds.
- */
- db_open(dbenv, &db_cats, "cats", 1);
-
- add_fruit(dbenv, db_fruit, "apple", "yellow delicious");
-
- add_color(dbenv, db_color, "blue", 0);
- add_color(dbenv, db_color, "blue", 3);
-
- return (0);
-}
-
-void
-add_color(DB_ENV *dbenv, DB *dbp, char *color, int increment)
-{
- DBT key, data;
- DB_TXN *tid;
- int original, ret;
- char buf64;
-
- /* Initialization. */
- memset(&key, 0, sizeof(key));
- key.data = color;
- key.size = strlen(color);
- memset(&data, 0, sizeof(data));
- data.flags = DB_DBT_MALLOC;
-
- for (;;) {
- /* Begin the transaction. */
- if ((ret = txn_begin(dbenv, NULL, &tid, 0)) != 0) {
- dbenv->err(dbenv, ret, "txn_begin");
- exit (1);
- }
-
- /*
- * Get the key. If it exists, we increment the value. If it
- * doesn't exist, we create it.
- */
- switch (ret = dbp->get(dbp, tid, &key, &data, 0)) {
- case 0:
- original = atoi(data.data);
- break;
- case DB_LOCK_DEADLOCK:
- /* Deadlock: retry the operation. */
- if ((ret = txn_abort(tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_abort");
- exit (1);
- }
- continue;
- case DB_NOTFOUND:
- original = 0;
- break;
- default:
- /* Error: run recovery. */
- dbenv->err(
- dbenv, ret, "dbc->get: %s/%d", color, increment);
- exit (1);
- }
- if (data.data != NULL)
- free(data.data);
-
- /* Create the new data item. */
- (void)snprintf(buf, sizeof(buf), "%d", original + increment);
- data.data = buf;
- data.size = strlen(buf) + 1;
-
- /* Store the new value. */
- switch (ret = dbp->put(dbp, tid, &key, &data, 0)) {
- case 0:
- /* Success: commit the change. */
- if ((ret = txn_commit(tid, 0)) != 0) {
- dbenv->err(dbenv, ret, "txn_commit");
- exit (1);
- }
- return;
- case DB_LOCK_DEADLOCK:
- /* Deadlock: retry the operation. */
- if ((ret = txn_abort(tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_abort");
- exit (1);
- }
- break;
- default:
- /* Error: run recovery. */
- dbenv->err(
- dbenv, ret, "dbc->put: %s/%d", color, increment);
- exit (1);
- }
- }
-} Any number of operations, on any number of databases, can be included
-in a single transaction to ensure atomicity of the operations. There
-is, however, a trade-off between the number of operations included in
-a single transaction and both throughput and the possibility of
-deadlock. The reason for this is because transactions acquire locks
-throughout their lifetime, and do not release them until transaction
-commit or abort. So, the more operations included in a transaction,
-the more likely that a transaction will block other operations and that
-deadlock will occur. However, each transaction commit requires a
-synchronous disk I/O, so grouping multiple operations into a transaction
-can increase overall throughput. (There is one exception to this. The
-DB_TXN_NOSYNC option causes transactions to exhibit the ACI
-(atomicity, consistency and isolation) properties, but not D
-(durability), avoiding the synchronous disk I/O on transaction commit
-and greatly increasing transaction throughput for some applications.
- When applications do create complex transactions, they often avoid
-having more than one complex transaction at a time, as simple operations
-like a single DB->put are unlikely to deadlock with each other
-or the complex transaction, while multiple complex transactions are
-likely to deadlock with each other as they will both acquire many locks
-over their lifetime. Alternatively, complex transactions can be broken
-up into smaller sets of operations, and each of those sets may be
-encapsulated in a nested transaction. Because nested transactions may
-be individually aborted and retried without causing the entire
-transaction to be aborted, this allows complex transactions to proceed
-even in the face of heavy contention, repeatedly trying the
-sub-operations until they succeed.
- It is also helpful to order operations within a transaction, that is,
-access the databases and items within the databases in the same order,
-to the extent possible, in all transactions. Accessing databases and
-items in different orders greatly increases the likelihood of operations
-being blocked and failing due to deadlocks.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/intro.html b/bdb/docs/ref/transapp/intro.html
deleted file mode 100644
index 758169e8552..00000000000
--- a/bdb/docs/ref/transapp/intro.html
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
-
-
-
- It is difficult to write a useful transactional tutorial and still keep
-within reasonable bounds of documentation, that is, without writing a
-book on transactional programming. We have two goals in this section:
-to familiarize readers with the transactional interfaces of Berkeley DB and
-to provide code building blocks that will be useful in creating
-applications.
- We have not attempted to present this information using a real-world
-application. First, transactional applications are often complex and
-time consuming to explain. Also, one of our goals is to give you an
-understanding of the wide variety of tools Berkeley DB makes available to you,
-and no single application would use most of the interfaces included in
-the Berkeley DB library. For these reasons, we have chosen to simply present
-the Berkeley DB data structures and programming solutions, using examples that
-differ from page to page. All of the examples are included in a
-standalone program you can examine, modify and run, and from which you
-will be able to extract code blocks for your own applications.
-Fragments of the program will be presented throughout this chapter, and
-the complete text of the example program
-for IEEE/ANSI Std 1003.1 (POSIX) standard systems is included in the Berkeley DB
-distribution.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/logfile.html b/bdb/docs/ref/transapp/logfile.html
deleted file mode 100644
index 64d8a96475e..00000000000
--- a/bdb/docs/ref/transapp/logfile.html
+++ /dev/null
@@ -1,104 +0,0 @@
-
-
-
-
-
- The fourth component of the infrastructure, log file removal, concerns
-the ongoing disk consumption of the database log files. Depending on
-the rate at which the application writes to the databases and the
-available disk space, the number of log files may increase quickly
-enough that disk space will be a resource problem. For this reason,
-you will periodically want to remove log files in order to conserve disk
-space. This procedure is distinct from database and log file archival
-for catastrophic recovery, and you cannot remove the current log files
-simply because you have created a database snapshot or copied log files
-to archival media.
- Log files may be removed at any time, as long as:
- Obviously, if you are preparing for catastrophic failure, you will want
-to copy the log files to archival media before you remove them.
- To remove log files, take the following steps:
- The functionality provided by the db_archive utility is also
-available directly from the Berkeley DB library. The following code fragment
-removes log files that are no longer needed by the database
-environment.
-
- /* Start a logfile removal thread. */
- if ((errno = pthread_create(
- &ptid, NULL, logfile_thread, (void *)dbenv)) != 0) {
- fprintf(stderr,
- "txnapp: failed spawning log file removal thread: %s\n",
- strerror(errno));
- exit (1);
- }
-
- ...
-}
-
-void *
-logfile_thread(void *arg)
-{
- DB_ENV *dbenv;
- int ret;
- char **begin, **list;
-
- dbenv = arg;
- dbenv->errx(dbenv,
- "Log file removal thread: %lu", (u_long)pthread_self());
-
- /* Check once every 5 minutes. */
- for (;; sleep(300)) {
- /* Get the list of log files. */
- if ((ret = log_archive(dbenv, &list, DB_ARCH_ABS, NULL)) != 0) {
- dbenv->err(dbenv, ret, "log_archive");
- exit (1);
- }
-
- /* Remove the log files. */
- if (list != NULL) {
- for (begin = list; *list != NULL; ++list)
- if ((ret = remove(*list)) != 0) {
- dbenv->err(dbenv,
- ret, "remove %s", *list);
- exit (1);
- }
- free (begin);
- }
- }
- /* NOTREACHED */
-} Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/put.html b/bdb/docs/ref/transapp/put.html
deleted file mode 100644
index e04a04f70bb..00000000000
--- a/bdb/docs/ref/transapp/put.html
+++ /dev/null
@@ -1,151 +0,0 @@
-
-
-
-
-
- The first reason listed for using transactions was recoverability. Any
-logical change to a database may require multiple changes to underlying
-data structures. For example, modifying a record in a Btree may require
-leaf and internal pages to split, and so a single DB->put method
-call can potentially require that multiple physical database pages be
-written. If only some of those pages are written and then the system
-or application fails, the database is left inconsistent and cannot be
-used until it has been recovered, that is, until the partially completed
-changes have been undone.
- Write-ahead-logging is the term that describes the underlying
-implementation that Berkeley DB uses to ensure recoverability. What it means
-is that before any change is made to a database, information about the
-change is written to a database log. During recovery, the log is read,
-and databases are checked to ensure that changes described in the log
-for committed transactions appear in the database. Changes that appear
-in the database but are related to aborted or unfinished transactions
-in the log are undone from the database.
- For recoverability after application or system failure, operations that
-modify the database must be protected by transactions. More
-specifically, operations are not recoverable unless a transaction is
-begun and each operation is associated with the transaction via the
-Berkeley DB interfaces, and then the transaction successfully committed. This
-is true even if logging is turned on in the database environment.
- Here is an example function that updates a record in a database in a
-transactionally protected manner. The function takes a key and data
-items as arguments, and then attempts to store them into the database.
-
- while ((ch = getopt(argc, argv, "")) != EOF)
- switch (ch) {
- case '?':
- default:
- usage();
- }
- argc -= optind;
- argv += optind;
-
- env_dir_create();
- env_open(&dbenv);
-
- /* Open database: Key is fruit class; Data is specific type. */
- db_open(dbenv, &db_fruit, "fruit", 0);
-
- /* Open database: Key is a color; Data is an integer. */
- db_open(dbenv, &db_color, "color", 0);
-
- /*
- * Open database:
- * Key is a name; Data is: company name, address, cat breeds.
- */
- db_open(dbenv, &db_cats, "cats", 1);
-
- add_fruit(dbenv, db_fruit, "apple", "yellow delicious");
-
- return (0);
-}
-
-void
-add_fruit(DB_ENV *dbenv, DB *db, char *fruit, char *name)
-{
- DBT key, data;
- DB_TXN *tid;
- int ret;
-
- /* Initialization. */
- memset(&key, 0, sizeof(key));
- memset(&data, 0, sizeof(data));
- key.data = fruit;
- key.size = strlen(fruit);
- data.data = name;
- data.size = strlen(name);
-
- for (;;) {
- /* Begin the transaction. */
- if ((ret = txn_begin(dbenv, NULL, &tid, 0)) != 0) {
- dbenv->err(dbenv, ret, "txn_begin");
- exit (1);
- }
-
- /* Store the value. */
- switch (ret = db->put(db, tid, &key, &data, 0)) {
- case 0:
- /* Success: commit the change. */
- if ((ret = txn_commit(tid, 0)) != 0) {
- dbenv->err(dbenv, ret, "txn_commit");
- exit (1);
- }
- return;
- case DB_LOCK_DEADLOCK:
- /* Deadlock: retry the operation. */
- if ((ret = txn_abort(tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_abort");
- exit (1);
- }
- break;
- default:
- /* Error: run recovery. */
- dbenv->err(dbenv, ret, "dbc->put: %s/%s", fruit, name);
- exit (1);
- }
- }
-} The second reason listed for using transactions was deadlock avoidance.
-There is a new error return in this function that you may not have seen
-before. In transactional (not Concurrent Data Store) applications
-supporting both readers and writers or just multiple writers, Berkeley DB
-functions have an additional possible error return:
-DB_LOCK_DEADLOCK. This return means that our thread of control
-deadlocked with another thread of control, and our thread was selected
-to discard all of its Berkeley DB resources in order to resolve the problem.
-In the sample code, any time the DB->put function returns
-DB_LOCK_DEADLOCK, the transaction is aborted (by calling
-txn_abort, which releases the transaction's Berkeley DB resources and
-undoes any partial changes to the databases), and then the transaction
-is retried from the beginning.
- There is no requirement that the transaction be attempted again, but
-that is a common course of action for applications. Applications may
-want to set an upper boundary on the number of times an operation will
-be retried, as some operations on some data sets may simply be unable
-to succeed. For example, updating all of the pages on a large web site
-during prime business hours may simply be impossible because of the high
-access rate to the database.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/read.html b/bdb/docs/ref/transapp/read.html
deleted file mode 100644
index 912401e8758..00000000000
--- a/bdb/docs/ref/transapp/read.html
+++ /dev/null
@@ -1,40 +0,0 @@
-
-
-
-
-
- The fourth reason listed for using transactions was repeatable reads.
-Generally, most applications do not need to place reads inside a
-transaction for performance reasons. The problem is that a
-transactionally protected cursor, reading each key/data pair in a
-database, will acquire a read lock on most of the pages in the database
-and so will gradually block all write operations on the databases until
-the transaction commits or aborts. Note, however, if there are update
-transactions present in the application, the reading transactions must
-still use locking, and should be prepared to repeat any operation
-(possibly closing and reopening a cursor) which fails with a return
-value of DB_LOCK_DEADLOCK.
- The exceptions to this rule are when the application is doing a
-read-modify-write operation and so requires atomicity, and when an
-application requires the ability to repeatedly access a data item
-knowing that it will not have changed. A repeatable read simply means
-that, for the life of the transaction, every time a request is made by
-any thread of control to read a data item, it will be unchanged from
-its previous value, that is, that the value will not change until the
-transaction commits or aborts.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/reclimit.html b/bdb/docs/ref/transapp/reclimit.html
deleted file mode 100644
index 559f8ed11b3..00000000000
--- a/bdb/docs/ref/transapp/reclimit.html
+++ /dev/null
@@ -1,106 +0,0 @@
-
-
-
-
-
- Berkeley DB recovery is based on write-ahead logging. What this means is that,
-when a change is made to a database page, a description of the change is
-written into a log file. This description in the log file is guaranteed
-to be written to stable storage before the database pages that were
-changed are written to stable storage. This is the fundamental feature
-of the logging system that makes durability and rollback work.
- If the application or system crashes, the log is reviewed during recovery.
-Any database changes described in the log that were part of committed
-transactions, and that were never written to the actual database itself,
-are written to the database as part of recovery. Any database changes
-described in the log that were never committed, and that were written to
-the actual database itself, are backed-out of the the database as part of
-recovery. This design allows the database to be written lazily, and only
-blocks from the log file have to be forced to disk as part of transaction
-commit.
- There are two interfaces that are a concern when considering Berkeley DB
-recoverability:
- Berkeley DB uses the operating system interfaces and its underlying filesystem
-when writing its files. This means that Berkeley DB can fail if the underlying
-filesystem fails in some unrecoverable way. Otherwise, the interface
-requirements here are simple: the system call that Berkeley DB uses to flush
-data to disk (normally fsync(2)), must guarantee that all the
-information necessary for a file's recoverability has been written to
-stable storage before it returns to Berkeley DB, and that no possible
-application or system crash can cause that file to be unrecoverable.
- In addition, Berkeley DB implicitly uses the interface between the operating
-system and the underlying hardware. The interface requirements here are
-not as simple.
- First, it is necessary to consider the underlying page size of the Berkeley DB
-databases. The Berkeley DB library performs all database writes using the page
-size specified by the application. These pages are not checksummed and
-Berkeley DB assumes that they are written atomically. This means that if the
-operating system performs filesystem I/O in different sized blocks than
-the database page size, it may increase the possibility for database
-corruption. For example, assume that Berkeley DB is writing 32KB pages for a
-database and the operating system does filesystem I/O in 16KB blocks. If
-the operating system writes the first 16KB of the database page
-successfully, but crashes before being able to write the second 16KB of
-the database, the database has been corrupted and this corruption will
-not be detected during recovery. For this reason, it may be important
-to select database page sizes that will be written as single block
-transfers by the underlying operating system.
- Second, it is necessary to consider the behavior of the system's underlying
-stable storage hardware. For example, consider a SCSI controller that
-has been configured to cache data and return to the operating system that
-the data has been written to stable storage, when, in fact, it has only
-been written into the controller RAM cache. If power is lost before the
-controller is able to flush its cache to disk, and the controller cache
-is not stable (i.e., the writes will not be flushed to disk when power
-returns), the writes will be lost. If the writes include database blocks,
-there is no loss as recovery will correctly update the database. If the
-writes include log file blocks, it is possible that transactions that were
-already committed may not appear in the recovered database, although the
-recovered database will be coherent after a crash.
- If the underlying hardware can fail in any way such that only part of the
-block was written, the failure conditions are the same as those described
-above for an operating system failure that only writes part of a logical
-database block.
- For these reasons, it is important to select hardware that does not do
-partial writes and does not cache data writes (or does not return that
-the data has been written to stable storage until it either has been
-written to stable storage or the actual writing of all of the data is
-guaranteed barring catastrophic hardware failure, e.g., your disk drive
-exploding). You should also be aware that Berkeley DB does not protect against
-all cases of stable storage hardware failure, nor does it protect against
-hardware misbehavior.
- If the disk drive on which you are storing your databases explodes, you
-can perform normal Berkeley DB catastrophic recovery, as that requires only a
-snapshot of your databases plus all of the log files you have archived
-since those snapshots were taken. In this case, you will lose no database
-changes at all. If the disk drive on which you are storing your log files
-explodes, you can still perform catastrophic recovery, but you will lose
-any database changes that were part of transactions committed since your
-last archival of the log files. For this reason, storing your databases
-and log files on different disks should be considered a safety measure as
-well as a performance enhancement.
- Finally, if your hardware misbehaves, for example, a SCSI controller
-writes incorrect data to the disk, Berkeley DB will not detect this and your
-data may be corrupted.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/recovery.html b/bdb/docs/ref/transapp/recovery.html
deleted file mode 100644
index 5be94bf417c..00000000000
--- a/bdb/docs/ref/transapp/recovery.html
+++ /dev/null
@@ -1,91 +0,0 @@
-
-
-
-
-
- The fifth component of the infrastructure, recovery procedures, concerns
-the recoverability of the database. After any application or system
-failure, there are two possible approaches to database recovery:
- During recovery processing, all database changes made by aborted or
-unfinished transactions are undone and all database changes made by
-committed transactions are redone, as necessary. Database applications
-must not be restarted until recovery completes. After recovery
-finishes, the environment is properly initialized so that applications
-may be restarted.
- If you intend to do recovery, there are two possible types of recovery
-processing:
- To restore your database environment after catastrophic failure, take
-the following steps:
- It is possible to recreate the database in a location different than
-the original, by specifying appropriate pathnames to the -h
-option of the db_recover utility. In order for this to work
-properly, it is important that your application reference files by
-names relative to the database home directory or the pathname(s) specified
-in calls to DBENV->set_data_dir, instead of using full path names.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/term.html b/bdb/docs/ref/transapp/term.html
deleted file mode 100644
index d6d54a44d29..00000000000
--- a/bdb/docs/ref/transapp/term.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
-
-
-
- Here are some definitions that will be helpful in understanding
-transactions:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/throughput.html b/bdb/docs/ref/transapp/throughput.html
deleted file mode 100644
index 734f3c7f9ab..00000000000
--- a/bdb/docs/ref/transapp/throughput.html
+++ /dev/null
@@ -1,117 +0,0 @@
-
-
-
-
-
- Generally, the speed of a database system is measured by the transaction
-throughput, expressed as the number of transactions per second. The two
-gating factors for Berkeley DB performance in a transactional system are usually
-the underlying database files and the log file. Both are factors because
-they require disk I/O, which is slow relative to other system resources
-like CPU.
- In the worst case scenario:
- This means that for each transaction, Berkeley DB is potentially performing
-several filesystem operations:
- There are a number of ways to increase transactional throughput, all of
-which attempt to decrease the number of filesystem operations per
-transaction:
- If you are bottlenecked on logging, the following test will help you
-confirm that the number of transactions per second that your application
-does is reasonable for the hardware on which you're running. Your test
-program should repeatedly perform the following operations:
- The number of times that you can perform these three operations per second
-is a rough measure of the number of transactions per second of which the
-hardware is capable. This test simulates the operations applied to the
-log file. (As a simplifying assumption in this experiment, we assume that
-the database files are either on a separate disk, or that they fit, with
-some few exceptions, into the database cache.) We do not have to directly
-simulate updating the log file directory information, as it will normally
-be updated and flushed to disk as a result of flushing the log file write
-to disk.
- Running this test program, where we write 256 bytes, for 1000 operations,
-on reasonably standard commodity hardware (Pentium II CPU, SCSI disk),
-returned the following results:
- Note that the number of bytes being written to the log as part of each
-transaction can dramatically affect the transaction throughput. The
-above test run used 256, which is a reasonable size log write. Your
-log writes may be different. To determine your average log write size,
-use the db_stat utility to display your log statistics.
- As a quick sanity check, for this particular disk, the average seek time
-is 9.4 msec, and the average latency is 4.17 msec. That results in a
-minimum requirement for a data transfer to the disk of 13.57 msec, or a
-maximum of 74 transfers per second. This is close enough to the above 60
-operations per second (which wasn't done on a quiescent disk) that the
-number is believable.
- An implementation of the above example test
-program for IEEE/ANSI Std 1003.1 (POSIX) standard systems is included in the Berkeley DB
-distribution.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/transapp.txt b/bdb/docs/ref/transapp/transapp.txt
deleted file mode 100644
index afd441c59f8..00000000000
--- a/bdb/docs/ref/transapp/transapp.txt
+++ /dev/null
@@ -1,492 +0,0 @@
-#include
- Perhaps the first question to answer is "Why transactions?" There are
-a number of reasons for including transactional support in your
-applications. The most common ones are:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/transapp/writetest.txt b/bdb/docs/ref/transapp/writetest.txt
deleted file mode 100644
index b86c1b6ce66..00000000000
--- a/bdb/docs/ref/transapp/writetest.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-/*
- * writetest --
- *
- * $Id: writetest.txt,v 10.3 1999/11/19 17:21:06 bostic Exp $
- */
-#include
- There is only a single parameter used in configuring transactions, the
-DB_TXN_NOSYNC flag. Setting the DB_TXN_NOSYNC flag to
-DBENV->set_flags when opening a transaction region changes the
-behavior of transactions not to synchronously flush the log during
-transaction commit.
- This change will significantly increase application transactional
-throughput. However, it means that while transactions will continue to
-exhibit the ACI (atomicity, consistency and isolation) properties, they
-will not have D (durability). Database integrity will be maintained but
-it is possible that some number of the most recently committed
-transactions may be undone during recovery instead of being redone.
- The application may also limit the number of simultaneous outstanding
-transactions supported by the environment by calling the
-DBENV->set_tx_max function. When this number is met, additional calls to
-txn_begin will fail until some active transactions complete.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/txn/intro.html b/bdb/docs/ref/txn/intro.html
deleted file mode 100644
index 557481509e0..00000000000
--- a/bdb/docs/ref/txn/intro.html
+++ /dev/null
@@ -1,86 +0,0 @@
-
-
-
-
-
- The transaction subsystem makes operations atomic, consistent, isolated,
-and durable in the face of system and application failures. The subsystem
-requires that the data be properly logged and locked in order to attain
-these properties. Berkeley DB contains all the components necessary to
-transaction-protect the Berkeley DB access methods and other forms of data may
-be protected if they are logged and locked appropriately.
- The transaction subsystem is created, initialized, and opened by calls to
-DBENV->open with the DB_INIT_TXN flag specified. Note that
-enabling transactions automatically enables logging, but does not enable
-locking, as a single thread of control that needed atomicity and
-recoverability would not require it.
- The txn_begin function starts a transaction, returning an opaque
-handle to a transaction. If the parent parameter to txn_begin is
-non-NULL, then the new transaction is a child of the designated parent
-transaction.
- The txn_abort function ends the designated transaction and causes
-all updates performed by the transaction to be undone. The end result is
-that the database is left in a state identical to the state that existed
-prior to the txn_begin. If the aborting transaction has any child
-transactions associated with it (even ones that have already been
-committed), they are also aborted. Any transactions that are unresolved
-(i.e., neither committed nor aborted) when the application or system fails
-are aborted during recovery.
- The txn_commit function ends the designated transaction and makes
-all the updates performed by the transaction permanent, even in the face
-of application or system failure. If this is a parent transaction
-committing, then all child transactions that individually committed or
-had not been resolved are also committed.
- Transactions are identified by 32-bit unsigned integers. The ID
-associated with any transaction can be obtained using the txn_id
-function. If an application is maintaining information outside of Berkeley DB
-that it wishes to transaction-protect, it should use this transaction ID
-as the locking ID.
- The txn_checkpoint function causes a transaction checkpoint. A
-checkpoint is performed relative to a specific log sequence number (LSN),
-referred to as the checkpoint LSN. When a checkpoint completes
-successfully, it means that all data buffers whose updates are described
-by LSNs less than the checkpoint LSN have been written to disk. This, in
-turn, means that the log records less than the checkpoint LSN are no
-longer necessary for normal recovery (although they would be required for
-catastrophic recovery should the database files be lost) and all log files
-containing only records prior to the checkpoint LSN may be safely archived
-and removed.
- It is possible that in order to complete a transaction checkpoint, it will
-be necessary to write a buffer that is currently in use (i.e., is actively
-being read or written by some transaction). In this case,
-txn_checkpoint will not be able to write the buffer, as doing so
-might cause an inconsistent version of the page to be written to disk,
-and instead of completing successfully will return with an error code of
-DB_INCOMPLETE. In such cases, the checkpoint can simply be
-retried after a short delay.
- The interval between successive checkpoints is directly proportional to
-the length of time required to run normal recovery. If the interval
-between checkpoints is long, then a large number of updates that are
-recorded in the log may not yet be written to disk and recovery may take
-longer to run. If the interval is short, then data is being written to
-disk more frequently, but the recovery time will be shorter. Often, the
-checkpoint interval will be tuned for each specific application.
- The txn_stat function returns information about the status of
-the transaction subsystem. It is the programmatic interface used by the
-db_stat utility.
- The transaction system is closed by a call to DBENV->close.
- Finally, the entire transaction system may be removed using the
-DBENV->remove interface.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/txn/limits.html b/bdb/docs/ref/txn/limits.html
deleted file mode 100644
index 0ed97806667..00000000000
--- a/bdb/docs/ref/txn/limits.html
+++ /dev/null
@@ -1,66 +0,0 @@
-
-
-
-
-
- Transactions are identified uniquely by 32-bit unsigned integers. The
-high-order bit of the transaction ID is reserved (and defined to be 1)
-resulting in just over two billion unique transaction IDs. Each time
-that recovery is run, the beginning transaction ID is reset with new
-transactions being numbered starting from 1. This means that recovery
-must be run at least once every two billion transactions.
- It is possible that some environments may need to be aware of this
-limitation. Consider an application performing 600 transactions a second
-for 15 hours a day. The transaction ID space will run out in roughly 66
-days:
- Doing only 100 transactions a second exhausts the transaction ID space
-in roughly one year.
- The transaction ID name space is initialized each time
-a database environment is created or recovered. If you
-reach the end of the transaction ID name space, it must
-be handled as if an application or system failure had
-occurred. The most recently allocated transaction ID
-is the st_last_txnid value in the transaction
-statistics information, and is displayed by the
-db_stat utility.
- When using transactions, cursors are localized to a single transaction.
-That is, a cursor may not span transactions and must be opened and
-closed within a single transaction. In addition, intermingling
-transaction-protected cursor operations and non-transaction-protected
-cursor operations on the same database in a single thread of control is
-practically guaranteed to deadlock as the locks obtained for transactions
-and non-transactions can conflict.
- Since transactions must hold all their locks until commit, a single
-transaction may accumulate a large number of long-term locks during its
-lifetime. As a result, when two concurrently running transactions access
-the same database, there is strong potential for conflict. While Berkeley
-DB allows an application to have multiple outstanding transactions active
-within a single thread of control, great care must be taken to ensure that
-the transactions do not interfere with each other (e.g., attempt to obtain
-conflicting locks on the same data). If two concurrently active
-transactions in the same thread of control do encounter a lock conflict,
-the thread of control will deadlock in such a manner that the deadlock
-detector will be unable to resolve the problem. In this case, there is
-no true deadlock, but because the transaction on which a transaction is
-waiting is in the same thread of control, no forward progress can be made.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/txn/nested.html b/bdb/docs/ref/txn/nested.html
deleted file mode 100644
index a635abf52a8..00000000000
--- a/bdb/docs/ref/txn/nested.html
+++ /dev/null
@@ -1,66 +0,0 @@
-
-
-
-
-
- Berkeley DB provides support for nested transactions. Nested transactions
-allow an application to decompose a large or long-running transaction
-into smaller units that may be independently aborted.
- Normally, when beginning a transaction, the application will pass a NULL
-value for the parent argument to txn_begin. If, however, the
-parent argument is a DB_TXN handle, then the newly created
-transaction will be treated as a nested transaction within the parent.
-Transactions may nest arbitrarily deeply. For the purposes of this
-discussion, transactions created with a parent identifier will be called
-child transactions.
- Once a transaction becomes a parent, as long as any of its child
-transactions are unresolved (i.e., they have neither committed nor
-aborted), the parent may not issue any Berkeley DB calls except to begin more
-child transactions or to commit or abort. That is, it may not issue
-any access method or cursor calls. Once all of a parent's children have
-committed or aborted, the parent may again request operations on its
-own behalf.
- The semantics of nested transactions are as follows. When a child
-transaction is begun, it inherits all the locks of its parent. This
-means that the child will never block waiting on a lock held by its
-parent. However, if a parent attempts to obtain locks after they have
-begun a child, the parental locks can conflict with those held by a
-child. Furthermore, locks held by two different children will also
-conflict. To make this concrete, consider the following set of
-transactions and lock acquisitions.
- Transaction T1 is the parent transaction. It acquires an exclusive lock
-on item A and then begins two child transactions, C1 and C2. C1 also
-wishes to acquire a write lock on A; this succeeds. Now, let's say that
-C1 acquires a write lock on B. If C2 now attempts to obtain a lock on
-B, it will block. However, let's now assume that C1 commits. Its locks
-are anti-inherited, which means they are now given to T1. At this
-point, either T1 or C2 is allowed to acquire a lock on B. If, however,
-transaction T1 aborts, then its locks are released. Future requests by
-T1 or C2 will also succeed, but they will be obtaining new locks as
-opposed to piggy-backing off a lock already held by T1.
- Child transactions are entirely subservient to their parent transaction.
-They may abort, undoing their operations regardless of the eventual fate
-of the parent. However, even if a child transaction commits, if its
-parent transaction is eventually aborted, the child's changes are undone
-and the child's transaction is effectively aborted. Any child
-transactions that are not yet resolved when the parent commits or aborts
-are resolved based on the parent's resolution, committing if the parent
-commits and aborting if the parent aborts. Any child transactions that
-are not yet resolved when the parent prepares are also prepared.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/txn/other.html b/bdb/docs/ref/txn/other.html
deleted file mode 100644
index e4678c2cbb0..00000000000
--- a/bdb/docs/ref/txn/other.html
+++ /dev/null
@@ -1,67 +0,0 @@
-
-
-
-
-
- It is possible to use the locking, logging and transaction subsystems
-of Berkeley DB to provide transaction semantics on objects other than those
-described by the Berkeley DB access methods. In these cases, the application
-will need more explicit customization of the subsystems as well as the
-development of appropriate data-structure-specific recovery functions.
- For example, consider an application that provides transaction semantics
-on data stored in plain UNIX files accessed using the POSIX read and write
-system calls. The operations for which transaction protection is desired
-are bracketed by calls to txn_begin and txn_commit.
- Before data are referenced, the application must make a call to the lock
-manager, lock_get, for a lock of the appropriate type (e.g.,
-read) on the object being locked. The object might be a page in the file,
-a byte, a range of bytes, or some key. It is up to the application to
-ensure that appropriate locks are acquired. Before a write is performed,
-the application should acquire a write lock on the object, by making an
-appropriate call to the lock manager, lock_get. Then, the
-application should make a call to the log manager, log_put, to
-record enough information to redo the operation in case of failure after
-commit and to undo the operation in case of abort.
- It is important, when designing applications that will use the log
-subsystem, to remember that the application is responsible for providing
-any necessary structure to the log record. For example, the application
-must understand what part of the log record is an operation code, what
-part identifies the file being modified, what part is redo information,
-and what part is undo information.
- After the log message is written, the application may issue the write
-system call. After all requests are issued, the application may call
-txn_commit. When txn_commit returns, the caller is
-guaranteed that all necessary log writes have been written to disk.
- At any time, the application may call txn_abort, which will result
-in restoration of the database to a consistent pre-transaction state.
-(The application may specify its own recovery function for this purpose
-using the DBENV->set_tx_recover function. The recovery function must be
-able to either re-apply or undo the update depending on the context, for
-each different type of log record.)
- If the application should crash, the recovery process uses the log to
-restore the database to a consistent state.
- The txn_prepare function provides the core functionality to
-implement distributed transactions, but it does not manage the
-notification of distributed transaction managers. The caller is
-responsible for issuing txn_prepare calls to all sites
-participating in the transaction. If all responses are positive, the
-caller can issue a txn_commit. If any of the responses are
-negative, the caller should issue a txn_abort. In general, the
-txn_prepare call requires that the transaction log be flushed to
-disk.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.2.0/convert.html b/bdb/docs/ref/upgrade.2.0/convert.html
deleted file mode 100644
index ad5685368dc..00000000000
--- a/bdb/docs/ref/upgrade.2.0/convert.html
+++ /dev/null
@@ -1,74 +0,0 @@
-
-
-
-
-
- Mapping the Berkeley DB 1.85 functionality into Berkeley DB version 2 is almost always
-simple. The manual page DB->open replaces the Berkeley DB 1.85 manual
-pages dbopen(3), btree(3), hash(3) and
-recno(3). You should be able to convert each 1.85 function
-call into a Berkeley DB version 2 function call using just the DB->open
-documentation.
- Some guidelines and things to watch out for:
- Specifically, the partial key match and range search functionality of the
-R_CURSOR flag in DB->seq has been replaced by the
-DB_SET_RANGE flag in DBcursor->c_get.
- While simply converting Berkeley DB 1.85 function calls to Berkeley DB version 2
-function calls will work, we recommend that you eventually reconsider your
-application's interface to the Berkeley DB database library in light of the
-additional functionality supplied by Berkeley DB version 2, as it is likely to
-result in enhanced application performance.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.2.0/disk.html b/bdb/docs/ref/upgrade.2.0/disk.html
deleted file mode 100644
index 8e7aeabc718..00000000000
--- a/bdb/docs/ref/upgrade.2.0/disk.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- You will need to upgrade your on-disk databases, as all access method
-database formats changed in the Berkeley DB 2.0 release. For information on
-converting databases from Berkeley DB 1.85 to Berkeley DB 2.0, see the
-db_dump185 and db_load documentation. As database
-environments did not exist prior to the 2.0 release, there is no
-question of upgrading existing database environments.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.2.0/intro.html b/bdb/docs/ref/upgrade.2.0/intro.html
deleted file mode 100644
index 1bebc81cbf5..00000000000
--- a/bdb/docs/ref/upgrade.2.0/intro.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-
-
-
- The following pages describe how to upgrade applications coded against
-the Berkeley DB 1.85 and 1.86 release interfaces to the Berkeley DB 2.0 release
-interfaces. They do not describe how to upgrade to the current Berkeley DB
-release interfaces.
- It is not difficult to upgrade Berkeley DB 1.85 applications to use the Berkeley DB
-version 2 library. The Berkeley DB version 2 library has a Berkeley DB 1.85
-compatibility API, which you can use by either recompiling your
-application's source code or by relinking its object files against the
-version 2 library. The underlying databases must be converted, however,
-as the Berkeley DB version 2 library has a different underlying database format.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.2.0/system.html b/bdb/docs/ref/upgrade.2.0/system.html
deleted file mode 100644
index 60a11c9bdf0..00000000000
--- a/bdb/docs/ref/upgrade.2.0/system.html
+++ /dev/null
@@ -1,84 +0,0 @@
-
-
-
-
-
- As the Berkeley DB 1.85 library did not have an installation target in the
-Makefile, there's no way to know exactly where it was installed on the
-system. In addition, many vendors included it in the C library instead
-of as a separate library, and so it may actually be part of libc and the
-db.h include file may be installed in /usr/include.
- For these reasons, the simplest way to maintain both libraries is to
-install Berkeley DB version 2 in a completely separate area of your system.
-The Berkeley DB version 2 installation process allows you to install into a
-standalone directory hierarchy on your system. See the
-Building for UNIX systems
-documentation for more information and instructions on how to install the
-Berkeley DB version 2 library, include files and documentation into specific
-locations.
- To replace 1.85 with version 2, you must either convert your 1.85
-applications to use the version 2 API or build the Berkeley DB version 2 library
-to include Berkeley DB 1.85 interface compatibility code. Whether converting
-your applications to use the version 2 interface or using the version 1.85
-compatibility API, you will need to recompile or relink your 1.85
-applications, and you must convert any persistent application databases
-to the Berkeley DB version 2 database formats.
- If you want to recompile your Berkeley DB 1.85 applications, you will have to
-change them to include the file db_185.h instead of
-db.h. (The db_185.h file is automatically installed
-during the Berkeley DB version 2 installation process.) You can then recompile
-the applications, linking them against the Berkeley DB version 2 library.
- For more information on compiling the Berkeley DB 1.85 compatibility code into
-the Berkeley DB version 2 library, see Building for UNIX platforms.
- For more information on converting databases from the Berkeley DB 1.85 formats
-to the Berkeley DB version 2 formats, see the db_dump185 and
-db_load documentation.
- The name space in Berkeley DB version 2 has been changed from that of previous
-Berkeley DB versions, notably version 1.85, for portability and consistency
-reasons. The only name collisions in the two libraries are the names used
-by the historic dbm, ndbm and hsearch interfaces,
-and the Berkeley DB 1.85 compatibility interfaces in the Berkeley DB version 2
-library.
- If you are loading both Berkeley DB 1.85 and Berkeley DB version 2 into a single
-library, remove the historic interfaces from one of the two library
-builds, and configure the Berkeley DB version 2 build to not include the Berkeley DB
-1.85 compatibility API, otherwise you could have collisions and undefined
-behavior. This can be done by editing the library Makefiles and
-reconfiguring and rebuilding the Berkeley DB version 2 library. Obviously, if
-you use the historic interfaces, you will get the version in the library
-from which you did not remove them. Similarly, you will not be able to
-access Berkeley DB version 2 files using the Berkeley DB 1.85 compatibility interface,
-since you have removed that from the library as well.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.2.0/toc.html b/bdb/docs/ref/upgrade.2.0/toc.html
deleted file mode 100644
index 68502be59cb..00000000000
--- a/bdb/docs/ref/upgrade.2.0/toc.html
+++ /dev/null
@@ -1,20 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/close.html b/bdb/docs/ref/upgrade.3.0/close.html
deleted file mode 100644
index 620e4babb8b..00000000000
--- a/bdb/docs/ref/upgrade.3.0/close.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- In previous Berkeley DB releases, the DB->close and DB->sync functions
-discarded any return of DB_INCOMPLETE from the underlying buffer
-pool interfaces, and returned success to its caller. (The
-DB_INCOMPLETE error will be returned if the buffer pool functions
-are unable to flush all of the database's dirty blocks from the pool.
-This often happens if another thread is reading or writing the database's
-pages in the pool.)
- In the 3.X release, DB->sync and DB->close will return
-DB_INCOMPLETE to the application. The best solution is to not
-call DB->sync and specify the DB_NOSYNC flag to the
-DB->close function when multiple threads are expected to be accessing the
-database. Alternatively, the caller can ignore any error return of
-DB_INCOMPLETE.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/cxx.html b/bdb/docs/ref/upgrade.3.0/cxx.html
deleted file mode 100644
index 7f6c1ab7ea9..00000000000
--- a/bdb/docs/ref/upgrade.3.0/cxx.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- The Db::set_error_model method is gone. The way to change the C++ API to
-return errors rather than throw exceptions is via a flag on the DbEnv or
-Db constructor. For example:
- creates an environment that will never throw exceptions, and method
-returns should be checked instead.
- There are a number of smaller changes to the API that bring the C, C++
-and Java APIs much closer in terms of functionality and usage. Please
-refer to the pages for upgrading C applications for further details.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/db.html b/bdb/docs/ref/upgrade.3.0/db.html
deleted file mode 100644
index a086b589e1b..00000000000
--- a/bdb/docs/ref/upgrade.3.0/db.html
+++ /dev/null
@@ -1,48 +0,0 @@
-
-
-
-
-
- The DB structure is now opaque for applications in the Berkeley DB 3.0
-release. Accesses to any fields within that structure by the application
-should be replaced with method calls. The following example illustrates
-this using the historic type structure field. In the Berkeley DB 2.X releases,
-applications could find the type of an underlying database using code
-similar to the following:
-
- type = db->type; in the Berkeley DB 3.X releases, this should be done using the
-DB->get_type method, as follows:
-
- type = db->get_type(db); The following table lists the DB fields previously used by
-applications and the methods that should now be used to get or set them.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/db_cxx.html b/bdb/docs/ref/upgrade.3.0/db_cxx.html
deleted file mode 100644
index e3a794e3865..00000000000
--- a/bdb/docs/ref/upgrade.3.0/db_cxx.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
-
- The static Db::open method and the DbInfo class have been removed in the
-Berkeley DB 3.0 release. The way to open a database file is to use the new Db
-constructor with two arguments, followed by set_XXX methods to configure
-the Db object, and finally a call to the new (nonstatic) Db::open(). In
-comparing the Berkeley DB 3.0 release open method with the 2.X static open
-method, the second argument is new. It is a database name, which can
-be null. The DbEnv argument has been removed, as the environment is now
-specified in the constructor. The open method no longer returns a Db,
-since it operates on one.
- Here's a C++ example opening a Berkeley DB database using the 2.X interface:
- In the Berkeley DB 3.0 release, this code would be written as:
- Here's a Java example opening a Berkeley DB database using the 2.X interface:
- In the Berkeley DB 3.0 release, this code would be written as:
- Note that if the dbenv argument is null, the database will not exist
-within an environment.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/dbenv.html b/bdb/docs/ref/upgrade.3.0/dbenv.html
deleted file mode 100644
index 08b6ec149ef..00000000000
--- a/bdb/docs/ref/upgrade.3.0/dbenv.html
+++ /dev/null
@@ -1,68 +0,0 @@
-
-
-
-
-
- The DB_ENV structure is now opaque for applications in the Berkeley DB
-3.0 release. Accesses to any fields within that structure by the
-application should be replaced with method calls. The following example
-illustrates this using the historic errpfx structure field. In the Berkeley DB
-2.X releases, applications set error prefixes using code similar to the
-following:
-
- dbenv->errpfx = "my prefix"; in the Berkeley DB 3.X releases, this should be done using the
-DBENV->set_errpfx method, as follows:
-
- dbenv->set_errpfx(dbenv, "my prefix"); The following table lists the DB_ENV fields previously used by
-applications and the methods that should now be used to set them.
- Note: the db_verbose field was a simple boolean toggle, the
-DBENV->set_verbose method takes arguments that specify exactly
-which verbose messages are desired. Note: the DBENV->set_cachesize function takes additional arguments.
-Setting both the second argument (the number of GB in the pool) and the
-last argument (the number of memory pools to create) to 0 will result in
-behavior that is backward compatible with previous Berkeley DB releases. Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/dbenv_cxx.html b/bdb/docs/ref/upgrade.3.0/dbenv_cxx.html
deleted file mode 100644
index 8839d640897..00000000000
--- a/bdb/docs/ref/upgrade.3.0/dbenv_cxx.html
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
-
-
-
- The DbEnv::appinit() method and two constructors for the DbEnv class are
-gone. There is now a single way to create and initialize the environment.
-The way to create an environment is to use the new DbEnv constructor with
-one argument. After this call, the DbEnv can be configured with various
-set_XXX methods. Finally, a call to DbEnv::open is made to initialize
-the environment.
- Here's a C++ example creating a Berkeley DB environment using the 2.X interface
-
-dbenv->set_error_stream(&cerr);
-dbenv->set_errpfx("myprog");
-
-if ((dberr = dbenv->appinit("/database/home",
- NULL, DB_CREATE | DB_INIT_LOCK | DB_INIT_MPOOL)) != 0) {
- cerr << "failure: " << strerror(dberr);
- exit (1);
-} In the Berkeley DB 3.0 release, this code would be written as:
-
-dbenv->set_error_stream(&cerr);
-dbenv->set_errpfx("myprog");
-
-if ((dberr = dbenv->open("/database/home",
- NULL, DB_CREATE | DB_INIT_LOCK | DB_INIT_MPOOL, 0)) != 0) {
- cerr << "failure: " << dbenv->strerror(dberr);
- exit (1);
-} Here's a Java example creating a Berkeley DB environment using the 2.X interface:
-
-dbenv.set_error_stream(System.err);
-dbenv.set_errpfx("myprog");
-
-dbenv.appinit("/database/home",
- null, Db.DB_CREATE | Db.DB_INIT_LOCK | Db.DB_INIT_MPOOL); In the Berkeley DB 3.0 release, this code would be written as:
-
-dbenv.set_error_stream(System.err);
-dbenv.set_errpfx("myprog");
-
-dbenv.open("/database/home",
- null, Db.DB_CREATE | Db.DB_INIT_LOCK | Db.DB_INIT_MPOOL, 0); In the Berkeley DB 2.X release, DbEnv had accessors to obtain "managers" of type
-DbTxnMgr, DbMpool, DbLog, DbTxnMgr. If you used any of these managers,
-all their methods are now found directly in the DbEnv class.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/dbinfo.html b/bdb/docs/ref/upgrade.3.0/dbinfo.html
deleted file mode 100644
index da1f8460d80..00000000000
--- a/bdb/docs/ref/upgrade.3.0/dbinfo.html
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
-
-
-
- The DB_INFO structure has been removed from the Berkeley DB 3.0 release.
-Accesses to any fields within that structure by the application should be
-replaced with method calls on the DB handle. The following
-example illustrates this using the historic db_cachesize structure field.
-In the Berkeley DB 2.X releases, applications could set the size of an
-underlying database cache using code similar to the following:
-
- memset(dbinfo, 0, sizeof(dbinfo));
- dbinfo.db_cachesize = 1024 * 1024; in the Berkeley DB 3.X releases, this should be done using the
-DB->set_cachesize method, as follows:
-
- ret = db->set_cachesize(db, 0, 1024 * 1024, 0); The DB_INFO structure is no longer used in any way by the Berkeley DB 3.0
-release, and should be removed from the application.
- The following table lists the DB_INFO fields previously used by
-applications and the methods that should now be used to set
-them. Because these calls provide configuration for the
-database open, they must precede the call to DB->open.
-Calling them after the call to DB->open will return an
-error.
- Note: the DB->set_cachesize function takes additional arguments.
-Setting both the second argument (the number of GB in the pool) and the
-last argument (the number of memory pools to create) to 0 will result in
-behavior that is backward compatible with previous Berkeley DB releases. Note: the DB_DELIMITER, DB_FIXEDLEN and DB_PAD flags no longer need to be
-set as there are specific methods off the DB handle that set the
-file delimiter, the length of fixed-length records and the fixed-length
-record pad character. They should simply be discarded from the application. Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/disk.html b/bdb/docs/ref/upgrade.3.0/disk.html
deleted file mode 100644
index f6ea2799be9..00000000000
--- a/bdb/docs/ref/upgrade.3.0/disk.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- Log file formats and the Btree, Recno and Hash Access Method database
-formats changed in the Berkeley DB 3.0 release. (The on-disk Btree/Recno
-format changed from version 6 to version 7. The on-disk Hash format
-changed from version 5 to version 6.) Until the underlying databases
-are upgraded, the DB->open function will return a DB_OLD_VERSION
-error.
- For further information on upgrading Berkeley DB installations, see
-Upgrading Berkeley DB
-installations.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/eacces.html b/bdb/docs/ref/upgrade.3.0/eacces.html
deleted file mode 100644
index b7fb3e8598a..00000000000
--- a/bdb/docs/ref/upgrade.3.0/eacces.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- There was an error in previous releases of the Berkeley DB documentation that
-said that the lock_put and lock_vec interfaces could
-return EACCES as an error to indicate that a lock could not be released
-because it was held by another locker. The application should be
-searched for any occurrences of EACCES. For each of these, any that are
-checking for an error return from lock_put or lock_vec
-should have the test and any error handling removed.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/eagain.html b/bdb/docs/ref/upgrade.3.0/eagain.html
deleted file mode 100644
index e998c1b4351..00000000000
--- a/bdb/docs/ref/upgrade.3.0/eagain.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- Historically, the Berkeley DB interfaces have returned the POSIX error value
-EAGAIN to indicate a deadlock. This has been removed from the Berkeley DB 3.0
-release in order to make it possible for applications to distinguish
-between EAGAIN errors returned by the system and returns from Berkeley DB
-indicating deadlock.
- The application should be searched for any occurrences of EAGAIN. For
-each of these, any that are checking for a deadlock return from Berkeley DB
-should be changed to check for the DB_LOCK_DEADLOCK return value.
- If, for any reason, this is a difficult change for the application to
-make, the include/db.src distribution file should be modified to
-translate all returns of DB_LOCK_DEADLOCK to EAGAIN. Search for the
-string EAGAIN in that file, there is a comment that describes how to make
-the change.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/envopen.html b/bdb/docs/ref/upgrade.3.0/envopen.html
deleted file mode 100644
index 3c20a0e9e21..00000000000
--- a/bdb/docs/ref/upgrade.3.0/envopen.html
+++ /dev/null
@@ -1,156 +0,0 @@
-
-
-
-
-
- The hardest part of upgrading your application from a 2.X code base to
-the 3.0 release is translating the Berkeley DB environment open, close and
-remove calls.
- There were two logical changes in this part of the Berkeley DB interface.
-First, in Berkeley DB 3.0, there are no longer separate structures that
-represent each subsystem (e.g., DB_LOCKTAB or DB_TXNMGR) and an overall
-DB_ENV environment structure. Instead there is only the
-DB_ENV structure. This means that DB_ENV references should
-be passed around by your application instead of passing around DB_LOCKTAB
-or DB_TXNMGR references. This is likely to be a simple change for most
-applications as few applications use the lock_XXX, log_XXX,
-memp_XXX or txn_XXX interfaces to create Berkeley DB environments.
- The second change is that there are no longer separate open, close, and
-unlink interfaces to the
-Berkeley DB subsystems, e.g., in previous releases, it was possible to open a
-lock subsystem either using db_appinit or using the lock_open call. In
-the 3.0 release the XXX_open interfaces to the subsystems have been
-removed, and subsystems must now be opened using the 3.0 replacement for the
-db_appinit call.
- To upgrade your application, first find each place your application opens,
-closes and/or removes a Berkeley DB environment. This will be code of the form:
- Each of these groups of calls should be replaced with calls to:
- The db_env_create call and the call to the DBENV->open
-method replace the db_appinit, lock_open, log_open, memp_open and txn_open
-calls. The DBENV->close method replaces the db_appexit,
-lock_close, log_close, memp_close and txn_close calls. The
-DBENV->remove call replaces the lock_unlink, log_unlink,
-memp_unlink and txn_unlink calls.
- Here's an example creating a Berkeley DB environment using the 2.X interface:
-
- if ((dbenv = (DB_ENV *)calloc(sizeof(DB_ENV), 1)) == NULL)
- return (errno);
-
- if ((errno = db_appinit(home, NULL, dbenv,
- DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN |
- DB_USE_ENVIRON)) == 0)
- return (dbenv);
-
- free(dbenv);
- return (NULL);
-} In the Berkeley DB 3.0 release, this code would be written as:
-
- if ((ret = db_env_create(&dbenv, 0)) != 0)
- return (ret);
-
- if ((ret = dbenv->open(dbenv, home, NULL,
- DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN |
- DB_USE_ENVIRON, 0)) == 0) {
- *dbenvp = dbenv;
- return (0);
- }
-
- (void)dbenv->close(dbenv, 0);
- return (ret);
-} As you can see, the arguments to db_appinit and to DBENV->open are
-largely the same. There is some minor re-organization: the mapping is
-that arguments #1, 2, 3, and 4 to db_appinit become arguments #2, 3, 1
-and 4 to DBENV->open. There is one additional argument to
-DBENV->open, argument #5. For backward compatibility with the 2.X
-Berkeley DB releases, simply set that argument to 0.
- It is only slightly more complex to translate calls to XXX_open to the
-DBENV->open method. Here's an example of creating a lock region
-using the 2.X interface:
- In the Berkeley DB 3.0 release, this code would be written as:
-
-if ((ret = dbenv->open(dbenv,
- dir, NULL, DB_CREATE | DB_INIT_LOCK, 0664)) == 0) {
- *dbenvp = dbenv;
- return (0);
-} Note that in this example, you no longer need the DB_LOCKTAB structure
-reference that was required in Berkeley DB 2.X releases.
- The final issue with upgrading the db_appinit call is the DB_MPOOL_PRIVATE
-option previously provided for the db_appinit interface. If your
-application is using this flag, it should almost certainly use the new
-DB_PRIVATE flag to the DBENV->open interface. Regardless,
-you should carefully consider this change before converting to use the
-DB_PRIVATE flag.
- Translating db_appexit or XXX_close calls to DBENV->close is equally
-simple. Instead of taking a reference to a per-subsystem structure such
-as DB_LOCKTAB or DB_TXNMGR, all calls take a reference to a DB_ENV
-structure. The calling sequence is otherwise unchanged. Note that as
-the application no longer allocates the memory for the DB_ENV structure,
-application code to discard it after the call to db_appexit() is no longer
-needed.
- Translating XXX_unlink calls to DBENV->remove is slightly more complex.
-As with DBENV->close, the call takes a reference to a DB_ENV
-structure instead of a per-subsystem structure. The calling sequence is
-slightly different, however. Here is an example of removing a lock region
-using the 2.X interface:
-
-ret = lock_unlink(dir, 1, dbenv); In the Berkeley DB 3.0 release, this code fragment would be written as:
-
-ret = dbenv->remove(dbenv, dir, NULL, DB_FORCE); The additional argument to the DBENV->remove function is a
-configuration argument similar to that previously taken by db_appinit and
-now taken by the DBENV->open method. For backward compatibility
-this new argument should simply be set to NULL. The force argument to
-XXX_unlink is now a flag value that is set by bitwise inclusively OR'ing it the
-DBENV->remove flag argument.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/func.html b/bdb/docs/ref/upgrade.3.0/func.html
deleted file mode 100644
index b6f7d816b49..00000000000
--- a/bdb/docs/ref/upgrade.3.0/func.html
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
-
-
-
- In Berkeley DB 3.0, there are no longer separate structures that
-represent each subsystem (e.g., DB_LOCKTAB or DB_TXNMGR), and an overall
-DB_ENV environment structure. Instead there is only the
-DB_ENV structure. This means that DB_ENV references should
-be passed around by your application instead of passing around DB_LOCKTAB
-or DB_TXNMGR references.
- Each of the following functions:
- should have its first argument, a reference to the DB_LOCKTAB structure,
-replaced with a reference to the enclosing DB_ENV structure. For
-example, the following line of code from a Berkeley DB 2.X application:
- should now be written as follows:
- Similarly, all of the functions:
- should have their DB_LOG argument replaced with a reference to a
-DB_ENV structure, and the functions:
- should have their DB_MPOOL argument replaced with a reference to a
-DB_ENV structure.
- You should remove all references to DB_LOCKTAB, DB_LOG, DB_MPOOL, and
-DB_TXNMGR structures from your application, they are no longer useful
-in any way. In fact, a simple way to identify all of the places that
-need to be upgraded is to remove all such structures and variables
-they declare, and then compile. You will see a warning message from
-your compiler in each case that needs to be upgraded.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/intro.html b/bdb/docs/ref/upgrade.3.0/intro.html
deleted file mode 100644
index a74e40f4ee7..00000000000
--- a/bdb/docs/ref/upgrade.3.0/intro.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
- The following pages describe how to upgrade applications coded against
-the Berkeley DB 2.X release interfaces to the Berkeley DB 3.0 release interfaces.
-This information does not describe how to upgrade Berkeley DB 1.85 release
-applications.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/java.html b/bdb/docs/ref/upgrade.3.0/java.html
deleted file mode 100644
index 3997095bc96..00000000000
--- a/bdb/docs/ref/upgrade.3.0/java.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- There are several additional types of exceptions thrown in the Berkeley DB 3.0
-Java API.
- DbMemoryException and DbDeadlockException can be caught independently of
-DbException if you want to do special handling for these kinds of errors.
-Since they are subclassed from DbException, a try block that catches
-DbException will catch these also, so code is not required to change.
-The catch clause for these new exceptions should appear before the catch
-clause for DbException.
- You will need to add a catch clause for java.io.FileNotFoundException,
-since that can be thrown by the Db.open and DbEnv.open functions.
- There are a number of smaller changes to the API that bring the C, C++
-and Java APIs much closer in terms of functionality and usage. Please
-refer to the pages for upgrading C applications for further details.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/join.html b/bdb/docs/ref/upgrade.3.0/join.html
deleted file mode 100644
index 82c9019fa1b..00000000000
--- a/bdb/docs/ref/upgrade.3.0/join.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- Historically, the last two arguments to the Berkeley DB DB->join
-interface were a flags value followed by a reference to a memory location
-to store the returned cursor object. In the Berkeley DB 3.0 release, the
-order of those two arguments has been swapped for consistency with other
-Berkeley DB interfaces.
- The application should be searched for any occurrences of DB->join.
-For each of these, the order of the last two arguments should be swapped.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/jump_set.html b/bdb/docs/ref/upgrade.3.0/jump_set.html
deleted file mode 100644
index c93e7270ee6..00000000000
--- a/bdb/docs/ref/upgrade.3.0/jump_set.html
+++ /dev/null
@@ -1,48 +0,0 @@
-
-
-
-
-
- The db_jump_set interface has been removed from the Berkeley DB 3.0 release,
-replaced by method calls on the DB_ENV handle.
- The following table lists the db_jump_set arguments previously used by
-applications and the methods that should now be used instead.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/lock_detect.html b/bdb/docs/ref/upgrade.3.0/lock_detect.html
deleted file mode 100644
index 4ff00a8a6b0..00000000000
--- a/bdb/docs/ref/upgrade.3.0/lock_detect.html
+++ /dev/null
@@ -1,24 +0,0 @@
-
-
-
-
-
- An additional argument has been added to the lock_detect interface.
- The application should be searched for any occurrences of lock_detect.
-For each one, a NULL argument should be appended to the current arguments.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/lock_notheld.html b/bdb/docs/ref/upgrade.3.0/lock_notheld.html
deleted file mode 100644
index 3f11738563e..00000000000
--- a/bdb/docs/ref/upgrade.3.0/lock_notheld.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- Historically, the Berkeley DB lock_put and lock_vec interfaces
-could return the DB_LOCK_NOTHELD error to indicate that a lock could
-not be released as it was held by another locker. This error can no
-longer be returned under any circumstances. The application should be
-searched for any occurrences of DB_LOCK_NOTHELD. For each of these,
-the test and any error processing should be removed.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/lock_put.html b/bdb/docs/ref/upgrade.3.0/lock_put.html
deleted file mode 100644
index d6057f8e291..00000000000
--- a/bdb/docs/ref/upgrade.3.0/lock_put.html
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
-
-
- An argument change has been made in the lock_put interface.
- The application should be searched for any occurrences of lock_put.
-For each one, instead of passing a DB_LOCK variable as the last argument
-to the function, the address of the DB_LOCK variable should be passed.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/lock_stat.html b/bdb/docs/ref/upgrade.3.0/lock_stat.html
deleted file mode 100644
index 80504db3bdf..00000000000
--- a/bdb/docs/ref/upgrade.3.0/lock_stat.html
+++ /dev/null
@@ -1,24 +0,0 @@
-
-
-
-
-
- The st_magic, st_version, st_numobjs and
-st_refcnt fields returned from the lock_stat interface
-have been removed, and this information is no longer available.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/log_register.html b/bdb/docs/ref/upgrade.3.0/log_register.html
deleted file mode 100644
index 3a856275ff0..00000000000
--- a/bdb/docs/ref/upgrade.3.0/log_register.html
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
-
-
- An argument has been removed from the log_register interface.
-The application should be searched for any occurrences of
-log_register. In each of these, the DBTYPE argument (it is the
-fourth argument) should be removed.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/log_stat.html b/bdb/docs/ref/upgrade.3.0/log_stat.html
deleted file mode 100644
index 8c023bfe26f..00000000000
--- a/bdb/docs/ref/upgrade.3.0/log_stat.html
+++ /dev/null
@@ -1,23 +0,0 @@
-
-
-
-
-
- The st_refcnt field returned from the log_stat interface
-has been removed, and this information is no longer available.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/memp_stat.html b/bdb/docs/ref/upgrade.3.0/memp_stat.html
deleted file mode 100644
index ff61fa745d6..00000000000
--- a/bdb/docs/ref/upgrade.3.0/memp_stat.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
- The st_refcnt field returned from the memp_stat interface
-has been removed, and this information is no longer available.
- The st_cachesize field returned from the memp_stat
-interface has been replaced with two new fields, st_gbytes and
-st_bytes.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/open.html b/bdb/docs/ref/upgrade.3.0/open.html
deleted file mode 100644
index 3730ab4749d..00000000000
--- a/bdb/docs/ref/upgrade.3.0/open.html
+++ /dev/null
@@ -1,65 +0,0 @@
-
-
-
-
-
- Database opens were changed in the Berkeley DB 3.0 release in a similar way to
-environment opens.
- To upgrade your application, first find each place your application opens
-a database, that is, calls the db_open function. Each of these calls
-should be replaced with calls to db_create and DB->open.
- Here's an example creating a Berkeley DB database using the 2.X interface:
-
-if ((ret = db_open(DATABASE,
- DB_BTREE, DB_CREATE, 0664, dbenv, NULL, &dbp)) != 0)
- return (ret); In the Berkeley DB 3.0 release, this code would be written as:
-
-if ((ret = db_create(&dbp, dbenv, 0)) != 0)
- return (ret);
-
-if ((ret = dbp->open(dbp,
- DATABASE, NULL, DB_BTREE, DB_CREATE, 0664)) != 0) {
- (void)dbp->close(dbp, 0);
- return (ret);
-} As you can see, the arguments to db_open and to DB->open are
-largely the same. There is some re-organization, and note that the
-enclosing DB_ENV structure is specified when the DB object
-is created using the db_create interface. There is one
-additional argument to DB->open, argument #3. For backward
-compatibility with the 2.X Berkeley DB releases, simply set that argument to
-NULL.
- There are two additional issues with the db_open call.
- First, it was possible in the 2.X releases for an application to provide
-an environment that did not contain a shared memory buffer pool as the
-database environment, and Berkeley DB would create a private one automatically.
-This functionality is no longer available, applications must specify the
-DB_INIT_MPOOL flag if databases are going to be opened in the
-environment.
- The final issue with upgrading the db_open call is that the DB_INFO
-structure is no longer used, having been replaced by individual methods
-on the DB handle. That change is discussed in detail later in
-this chapter.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/rmw.html b/bdb/docs/ref/upgrade.3.0/rmw.html
deleted file mode 100644
index a1a30da5ecf..00000000000
--- a/bdb/docs/ref/upgrade.3.0/rmw.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- The following change applies only to applications using the
-Berkeley DB Concurrent Data Store product. If your application is not using that product,
-you can ignore this change.
- Historically, the Berkeley DB DB->cursor interface took the DB_RMW flag
-to indicate that the created cursor would be used for write operations on
-the database. This flag has been renamed to the DB_WRITECURSOR
-flag.
- The application should be searched for any occurrences of DB_RMW. For
-each of these, any that are arguments to the DB->cursor function
-should be changed to pass in the DB_WRITECURSOR flag instead.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/stat.html b/bdb/docs/ref/upgrade.3.0/stat.html
deleted file mode 100644
index 735e235d9cd..00000000000
--- a/bdb/docs/ref/upgrade.3.0/stat.html
+++ /dev/null
@@ -1,24 +0,0 @@
-
-
-
-
-
- The bt_flags field returned from the DB->stat interface
-for Btree and Recno databases has been removed, and this information is
-no longer available.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/toc.html b/bdb/docs/ref/upgrade.3.0/toc.html
deleted file mode 100644
index 189d7c0a657..00000000000
--- a/bdb/docs/ref/upgrade.3.0/toc.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/txn_begin.html b/bdb/docs/ref/upgrade.3.0/txn_begin.html
deleted file mode 100644
index 3fb9a6527d4..00000000000
--- a/bdb/docs/ref/upgrade.3.0/txn_begin.html
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
-
-
- An additional argument has been added to the txn_begin interface.
- The application should be searched for any occurrences of
-txn_begin. For each one, an argument of 0 should be appended to
-the current arguments.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/txn_commit.html b/bdb/docs/ref/upgrade.3.0/txn_commit.html
deleted file mode 100644
index 8090b1e3b84..00000000000
--- a/bdb/docs/ref/upgrade.3.0/txn_commit.html
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
-
-
- An additional argument has been added to the txn_commit interface.
- The application should be searched for any occurrences of
-txn_commit. For each one, an argument of 0 should be appended to
-the current arguments.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/txn_stat.html b/bdb/docs/ref/upgrade.3.0/txn_stat.html
deleted file mode 100644
index d965494d5ef..00000000000
--- a/bdb/docs/ref/upgrade.3.0/txn_stat.html
+++ /dev/null
@@ -1,23 +0,0 @@
-
-
-
-
-
- The st_refcnt field returned from the txn_stat interface
-has been removed, and this information is no longer available.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/value_set.html b/bdb/docs/ref/upgrade.3.0/value_set.html
deleted file mode 100644
index 66070b09fd6..00000000000
--- a/bdb/docs/ref/upgrade.3.0/value_set.html
+++ /dev/null
@@ -1,41 +0,0 @@
-
-
-
-
-
- The db_value_set interface has been removed from the Berkeley DB 3.0 release,
-replaced by method calls on the DB_ENV handle.
- The following table lists the db_value_set arguments previously used by
-applications and the methods that should now be used instead.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.0/xa.html b/bdb/docs/ref/upgrade.3.0/xa.html
deleted file mode 100644
index 41f5a993d23..00000000000
--- a/bdb/docs/ref/upgrade.3.0/xa.html
+++ /dev/null
@@ -1,33 +0,0 @@
-
-
-
-
-
- The following change applies only to applications using Berkeley DB as an XA
-Resource Manager. If your application is not using Berkeley DB in this way,
-you can ignore this change.
- The db_xa_open function has been replaced with the DB_XA_CREATE
-flag to the db_create function. All calls to db_xa_open should
-be replaced with calls to db_create with the DB_XA_CREATE
-flag set, followed by a call to the DB->open function.
- A similar change has been made for the C++ API, where the
-DB_XA_CREATE flag should be specified to the Db constructor. All
-calls to the Db::xa_open method should be replaced with the
-DB_XA_CREATE flag to the Db constructor, followed by a call to
-the DB::open method.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/btstat.html b/bdb/docs/ref/upgrade.3.1/btstat.html
deleted file mode 100644
index e5d7c4bb5d5..00000000000
--- a/bdb/docs/ref/upgrade.3.1/btstat.html
+++ /dev/null
@@ -1,50 +0,0 @@
-
-
-
-
-
- For Btree database statistics, the DB->stat interface field
-bt_nrecs has been removed, replaced by two fields:
-bt_nkeys and bt_ndata. The bt_nkeys field returns
-a count of the unique keys in the database. The bt_ndata field
-returns a count of the key/data pairs in the database. Neither exactly
-matches the previous value of the bt_nrecs field, which returned
-a count of keys in the database, but, in the case of Btree databases,
-could overcount as it sometimes counted duplicate data items as unique
-keys. The application should be searched for any uses of the
-bt_nrecs field and the field should be changed to be either
-bt_nkeys or bt_ndata, whichever is more appropriate.
- For Hash database statistics, the DB->stat interface field
-hash_nrecs has been removed, replaced by two fields:
-hash_nkeys and hash_ndata. The hash_nkeys field
-returns a count of the unique keys in the database. The
-hash_ndata field returns a count of the key/data pairs in the
-database. The new hash_nkeys field exactly matches the previous
-value of the hash_nrecs field. The application should be searched
-for any uses of the hash_nrecs field, and the field should be
-changed to be hash_nkeys.
- For Queue database statistics, the DB->stat interface field
-qs_nrecs has been removed, replaced by two fields:
-qs_nkeys and qs_ndata. The qs_nkeys field returns
-a count of the unique keys in the database. The qs_ndata field
-returns a count of the key/data pairs in the database. The new
-qs_nkeys field exactly matches the previous value of the
-qs_nrecs field. The application should be searched for any uses
-of the qs_nrecs field, and the field should be changed to be
-qs_nkeys.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/config.html b/bdb/docs/ref/upgrade.3.1/config.html
deleted file mode 100644
index 29a53363eaf..00000000000
--- a/bdb/docs/ref/upgrade.3.1/config.html
+++ /dev/null
@@ -1,35 +0,0 @@
-
-
-
-
-
- In the Berkeley DB 3.1 release, the config argument to the
-DBENV->open, DBENV->remove methods has been removed,
-replaced by additional methods on the DB_ENV handle. If your
-application calls DBENV->open or DBENV->remove with a NULL
-config argument, find those functions and remove the config
-argument from the call. If your application has non-NULL config
-argument, the strings values in that argument are replaced with calls to
-DB_ENV methods as follows:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/disk.html b/bdb/docs/ref/upgrade.3.1/disk.html
deleted file mode 100644
index cbaa3342b5f..00000000000
--- a/bdb/docs/ref/upgrade.3.1/disk.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- Log file formats and the Btree, Queue, Recno and Hash Access Method
-database formats changed in the Berkeley DB 3.1 release. (The on-disk
-Btree/Recno format changed from version 7 to version 8. The on-disk
-Hash format changed from version 6 to version 7. The on-disk Queue
-format changed from version 1 to version 2.) Until the underlying
-databases are upgraded, the DB->open function will return a
-DB_OLD_VERSION error.
- An additional flag, DB_DUPSORT, has been added to the
-DB->upgrade function for this upgrade. Please review the
-DB->upgrade documentation for further information.
- For further information on upgrading Berkeley DB installations, see
-Upgrading Berkeley DB
-installations.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/dup.html b/bdb/docs/ref/upgrade.3.1/dup.html
deleted file mode 100644
index 33f71ebb418..00000000000
--- a/bdb/docs/ref/upgrade.3.1/dup.html
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
-
-
-
- In previous releases of Berkeley DB, it was not an error to store identical
-duplicate data items, or, for those that just like the way it sounds,
-duplicate duplicates. However, there were implementation bugs where
-storing duplicate duplicates could cause database corruption.
- In this release, applications may store identical duplicate data items
-as long as the data items are unsorted. It is an error to attempt to
-store identical duplicate data items when duplicates are being stored
-in a sorted order. This restriction is expected to be lifted in a future
-release. See Duplicate data items
-for more information.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/env.html b/bdb/docs/ref/upgrade.3.1/env.html
deleted file mode 100644
index 6e1b8ccde53..00000000000
--- a/bdb/docs/ref/upgrade.3.1/env.html
+++ /dev/null
@@ -1,53 +0,0 @@
-
-
-
-
-
- A set of DB_ENV configuration methods which were not environment
-specific, but which instead affected the entire application space, have
-been removed from the DB_ENV object and replaced by static
-functions. The following table lists the DB_ENV methods previously
-available to applications and the static functions that should now be used
-instead.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/intro.html b/bdb/docs/ref/upgrade.3.1/intro.html
deleted file mode 100644
index 9c5d9529158..00000000000
--- a/bdb/docs/ref/upgrade.3.1/intro.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
- The following pages describe how to upgrade applications coded against
-the Berkeley DB 3.0 release interfaces to the Berkeley DB 3.1 release interfaces.
-This information does not describe how to upgrade Berkeley DB 1.85 release
-applications.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/log_register.html b/bdb/docs/ref/upgrade.3.1/log_register.html
deleted file mode 100644
index 8823d643953..00000000000
--- a/bdb/docs/ref/upgrade.3.1/log_register.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- The arguments to the log_register and log_unregister
-interfaces have changed. Instead of returning (and passing in) a logging
-file ID, a reference to the DB structure being registered (or
-unregistered) is passed. The application should be searched for any
-occurrences of log_register and log_unregister. For each
-one, change the arguments to be a reference to the DB structure
-being registered or unregistered.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/logalloc.html b/bdb/docs/ref/upgrade.3.1/logalloc.html
deleted file mode 100644
index acafbf6ee0a..00000000000
--- a/bdb/docs/ref/upgrade.3.1/logalloc.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- This change only affects Win/32 applications.
- On Win/32 platforms Berkeley DB no longer pre-allocates log files. The problem
-was a noticeable performance spike as each log file was created. To turn
-this feature back on, search for the flag DB_OSO_LOG in the source file
-log/log_put.c and make the change described there, or contact
-Sleepycat Software for assistance.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/memp_register.html b/bdb/docs/ref/upgrade.3.1/memp_register.html
deleted file mode 100644
index e8a667031e6..00000000000
--- a/bdb/docs/ref/upgrade.3.1/memp_register.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- An additional argument has been added to the pgin and
-pgout functions provided to the memp_register interface.
-The application should be searched for any occurrences of
-memp_register. For each one, if pgin or pgout
-functions are specified, the pgin and pgout functions
-should be modified to take an initial argument of a DB_ENV *.
-This argument is intended to support better error reporting for
-applications, and may be entirely ignored by the pgin and
-pgout functions themselves.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/put.html b/bdb/docs/ref/upgrade.3.1/put.html
deleted file mode 100644
index 5252b3ac00a..00000000000
--- a/bdb/docs/ref/upgrade.3.1/put.html
+++ /dev/null
@@ -1,63 +0,0 @@
-
-
-
-
-
- For the Queue and Recno access methods, when the DB_APPEND flag
-is specified to the DB->put interface, the allocated record number
-is returned to the application in the key DBT argument.
-In previous releases of Berkeley DB, this DBT structure did not follow
-the usual DBT conventions, e.g., it was not possible to cause
-Berkeley DB to allocate space for the returned record number. Rather, it was
-always assumed that the data field of the key structure
-referenced memory that could be used as storage for a db_recno_t type.
- As of the Berkeley DB 3.1.0 release, the key structure behaves as
-described in the DBT C++/Java class or C structure documentation.
- Applications which are using the DB_APPEND flag for Queue and
-Recno access method databases will require a change to upgrade to the
-Berkeley DB 3.1 releases. The simplest change is likely to be to add the
-DB_DBT_USERMEM flag to the key structure. For example,
-code that appears as follows:
-
-memset(&key, 0, sizeof(DBT));
-key.data = &recno;
-key.size = sizeof(recno);
-DB->put(DB, NULL, &key, &data, DB_APPEND);
-printf("new record number is %lu\n", (u_long)recno); would be changed to:
-
-memset(&key, 0, sizeof(DBT));
-key.data = &recno;
-key.ulen = sizeof(recno);
-key.flags = DB_DBT_USERMEM;
-DB->put(DB, NULL, &key, &data, DB_APPEND);
-printf("new record number is %lu\n", (u_long)recno); Note that the ulen field is now set as well as the flag value.
-An alternative change would be:
-
-memset(&key, 0, sizeof(DBT));
-DB->put(DB, NULL, &key, &data, DB_APPEND);
-recno = *(db_recno_t *)key->data;
-printf("new record number is %lu\n", (u_long)recno); Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/set_feedback.html b/bdb/docs/ref/upgrade.3.1/set_feedback.html
deleted file mode 100644
index c7b7864b9d2..00000000000
--- a/bdb/docs/ref/upgrade.3.1/set_feedback.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- Starting with the 3.1 release of Berkeley DB, the DBENV->set_feedback
-and DB->set_feedback functions may return an error value, that is, they
-are no longer declared as returning no value, instead they return an int
-or throw an exception as appropriate when an error occurs.
- If your application calls these functions, you may want to check for a
-possible error on return.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/set_paniccall.html b/bdb/docs/ref/upgrade.3.1/set_paniccall.html
deleted file mode 100644
index 8aa554cf067..00000000000
--- a/bdb/docs/ref/upgrade.3.1/set_paniccall.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- Starting with the 3.1 release of Berkeley DB, the DBENV->set_paniccall
-and DB->set_paniccall functions may return an error value, that is, they
-are no longer declared as returning no value, instead they return an int
-or throw an exception as appropriate when an error occurs.
- If your application calls these functions, you may want to check for a
-possible error on return.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/set_tx_recover.html b/bdb/docs/ref/upgrade.3.1/set_tx_recover.html
deleted file mode 100644
index 9943845e864..00000000000
--- a/bdb/docs/ref/upgrade.3.1/set_tx_recover.html
+++ /dev/null
@@ -1,36 +0,0 @@
-
-
-
-
-
- The redo parameter of the function passed to DBENV->set_tx_recover
-used to be an integer set to any one of a number of #defined values. In
-the 3.1 release of Berkeley DB, the redo parameter has been replaced by the op
-parameter which is an enumerated type of type db_recops.
- If your application calls DBENV->set_tx_recover, then find the
-function referenced in the call. Replace the flag values in that function
-as follows:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/sysmem.html b/bdb/docs/ref/upgrade.3.1/sysmem.html
deleted file mode 100644
index 7e21a565e97..00000000000
--- a/bdb/docs/ref/upgrade.3.1/sysmem.html
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
-
-
- Using the DB_SYSTEM_MEM option on UNIX systems now requires the
-specification of a base system memory segment ID, using the
-DBENV->set_shm_key function. Any valid segment ID may be specified, for
-example, one returned by the UNIX ftok(3) interface.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/tcl.html b/bdb/docs/ref/upgrade.3.1/tcl.html
deleted file mode 100644
index 0f964abb31e..00000000000
--- a/bdb/docs/ref/upgrade.3.1/tcl.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-
- The Berkeley DB Tcl API has been modified so that the -mpool option to
-the berkdb env command is now the default behavior. The Tcl API
-has also been modified so that the -txn option to the
-berkdb env command implies the -lock and -log
-options. Tcl scripts should be updated to remove the -mpool,
--lock and -log options.
- The Berkeley DB Tcl API has been modified to follow the Tcl standard rules for
-integer conversion, e.g., if the first two characters of a record number
-are "0x", the record number is expected to be in hexadecimal form.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/tmp.html b/bdb/docs/ref/upgrade.3.1/tmp.html
deleted file mode 100644
index 72034803b1b..00000000000
--- a/bdb/docs/ref/upgrade.3.1/tmp.html
+++ /dev/null
@@ -1,34 +0,0 @@
-
-
-
-
-
- This change only affects Win/32 applications that create in-memory
-databases.
- On Win/32 platforms an additional test has been added when searching for
-the appropriate directory in which to create the temporary files that are
-used to back in-memory databases. Berkeley DB now uses any return value from
-the GetTempPath interface as the temporary file directory name before
-resorting to the static list of compiled-in pathnames.
- If the system registry does not return the same directory as Berkeley DB has
-been using previously, this change could cause temporary backing files to
-move to a new directory when applications are upgraded to the 3.1 release.
-In extreme cases, this could create (or fix) security problems if the file
-protection modes for the system registry directory are different from
-those on the directory previously used by Berkeley DB.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/toc.html b/bdb/docs/ref/upgrade.3.1/toc.html
deleted file mode 100644
index 091318810da..00000000000
--- a/bdb/docs/ref/upgrade.3.1/toc.html
+++ /dev/null
@@ -1,33 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.1/txn_check.html b/bdb/docs/ref/upgrade.3.1/txn_check.html
deleted file mode 100644
index 27dc3851f7e..00000000000
--- a/bdb/docs/ref/upgrade.3.1/txn_check.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
- An additional argument has been added to the txn_checkpoint
-interface.
- The application should be searched for any occurrences of
-txn_checkpoint. For each one, an argument of 0 should be appended
-to the current arguments.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/callback.html b/bdb/docs/ref/upgrade.3.2/callback.html
deleted file mode 100644
index f60a81d5c56..00000000000
--- a/bdb/docs/ref/upgrade.3.2/callback.html
+++ /dev/null
@@ -1,39 +0,0 @@
-
-
-
-
-
- In the Berkeley DB 3.2 release, four application callback functions (the
-callback functions set by DB->set_bt_compare,
-DB->set_bt_prefix, DB->set_dup_compare and
-DB->set_h_hash) were modified to take a reference to a
-DB object as their first argument. This change allows the Berkeley DB
-Java API to reasonably support these interfaces. There is currently no
-need for the callback functions to do anything with this additional
-argument.
- C and C++ applications that specify their own Btree key comparison,
-Btree prefix comparison, duplicate data item comparison or Hash
-functions should modify these functions to take a reference to a
-DB structure as their first argument. No further change is
-required.
- The app_private field of the DBT structure (accessible only from
-the Berkeley DB C API) has been removed in the 3.2 release. It was replaced
-with app_private fields in the DB_ENV and DB handles.
-Applications using this field will have to convert to using one of the
-replacement fields.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/db_dump.html b/bdb/docs/ref/upgrade.3.2/db_dump.html
deleted file mode 100644
index 87d909086b3..00000000000
--- a/bdb/docs/ref/upgrade.3.2/db_dump.html
+++ /dev/null
@@ -1,29 +0,0 @@
-
-
-
-
-
- In previous releases of Berkeley DB, the db_dump utility dumped Recno
-access method database keys as numeric strings. For consistency, the
-db_dump utility has been changed in the 3.2 release to dump
-record numbers as hex pairs when the data items are being dumped as hex
-pairs. (See the -k and -p options to the
-db_dump utility for more information.) Any applications or
-scripts post-processing the db_dump output of Recno databases
-under these conditions may require modification.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/disk.html b/bdb/docs/ref/upgrade.3.2/disk.html
deleted file mode 100644
index 8cebb9319ec..00000000000
--- a/bdb/docs/ref/upgrade.3.2/disk.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- Log file formats and the Queue Access Method database formats changed
-in the Berkeley DB 3.2 release. (The on-disk Queue format changed from
-version 2 to version 3.) Until the underlying databases are upgraded,
-the DB->open function will return a DB_OLD_VERSION error.
- For further information on upgrading Berkeley DB installations, see
-Upgrading Berkeley DB
-installations.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/handle.html b/bdb/docs/ref/upgrade.3.2/handle.html
deleted file mode 100644
index 86f86a03a93..00000000000
--- a/bdb/docs/ref/upgrade.3.2/handle.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
-
- In previous releases of Berkeley DB, Java DbEnv and Db
-objects, and C++ DbEnv and Db objects could be
-re-used after they were closed, by calling open on them again. This is
-no longer permitted, and these objects no longer allow any operations
-after a close. Applications re-using these objects should be modified
-to create new objects instead.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/incomplete.html b/bdb/docs/ref/upgrade.3.2/incomplete.html
deleted file mode 100644
index 5aeb7755952..00000000000
--- a/bdb/docs/ref/upgrade.3.2/incomplete.html
+++ /dev/null
@@ -1,39 +0,0 @@
-
-
-
-
-
- There are a number of functions that flush pages from the Berkeley DB shared
-memory buffer pool to disk. Most of those functions can potentially
-fail because a page that needs to be flushed is not currently available.
-However, this is not a hard failure and is rarely cause for concern.
-In the Berkeley DB 3.2 release, the C++ API (if that API is configured to
-throw exceptions) and the Java API have been changed so that this
-failure does not throw an exception, but rather returns a non-zero error
-code of DB_INCOMPLETE.
- The following C++ methods will return DB_INCOMPLETE rather than throw
-an exception: Db::close, Db::sync, DbEnv::memp_sync,
-DbEnv::txn_checkpoint, DbMpoolFile::sync.
- The following Java methods are now declared "public int" rather than
-"public void", and will return Db.DB_INCOMPLETE rather than
-throw an exception: Db.close, Db.sync,
-DbEnv.txn_checkpoint.
- It is likely that the only change required by any application will be
-those currently checking for a DB_INCOMPLETE return that has
-been encapsulated in an exception.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/intro.html b/bdb/docs/ref/upgrade.3.2/intro.html
deleted file mode 100644
index df4d573a087..00000000000
--- a/bdb/docs/ref/upgrade.3.2/intro.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
- The following pages describe how to upgrade applications coded against
-the Berkeley DB 3.1 release interfaces to the Berkeley DB 3.2 release interfaces.
-This information does not describe how to upgrade Berkeley DB 1.85 release
-applications.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/mutexlock.html b/bdb/docs/ref/upgrade.3.2/mutexlock.html
deleted file mode 100644
index fb1b87ca9ed..00000000000
--- a/bdb/docs/ref/upgrade.3.2/mutexlock.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
- Previous Berkeley DB releases included the db_env_set_mutexlocks interface,
-intended for debugging, that allows applications to always obtain
-requested mutual exclusion mutexes without regard for their
-availability. This interface has been replaced with
-DBENV->set_mutexlocks, which provides the same functionality on
-a per-database environment basis. Applications using the old interface
-should be updated to use the new one.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/notfound.html b/bdb/docs/ref/upgrade.3.2/notfound.html
deleted file mode 100644
index cb40beaae22..00000000000
--- a/bdb/docs/ref/upgrade.3.2/notfound.html
+++ /dev/null
@@ -1,25 +0,0 @@
-
-
-
-
-
- The Java DbEnv.remove, Db.remove and
-Db.rename methods now throw java.io.FileNotFoundException
-in the case where the named file does not exist. Applications should
-be modified to catch this exception where appropriate.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/renumber.html b/bdb/docs/ref/upgrade.3.2/renumber.html
deleted file mode 100644
index 619fa07ff0e..00000000000
--- a/bdb/docs/ref/upgrade.3.2/renumber.html
+++ /dev/null
@@ -1,39 +0,0 @@
-
-
-
-
-
- In the Berkeley DB 3.2 release, cursor adjustment semantics changed for Recno
-databases with mutable record numbers. Before the 3.2 release, cursors
-were adjusted to point to the previous or next record at the time the
-record referenced by the cursor was deleted. This could lead to
-unexpected behaviors. For example, two cursors referencing sequential
-records that were both deleted would lose their relationship to each
-other and would reference the same position in the database instead of
-their original sequential relationship. There were also command
-sequences that would have unexpected results. For example, DB_AFTER
-and DB_BEFORE cursor put operations, using a cursor previously used to
-delete an item, would perform the put relative to the cursor's adjusted
-position and not its original position.
- In the Berkeley DB 3.2 release, cursors maintain their position in the tree
-regardless of deletion operations using the cursor. Applications that
-perform database operations, using cursors previously used to delete
-entries in Recno databases with mutable record numbers, should be
-evaluated to ensure that the new semantics do not cause application
-failure.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/set_flags.html b/bdb/docs/ref/upgrade.3.2/set_flags.html
deleted file mode 100644
index b1bbe906b2d..00000000000
--- a/bdb/docs/ref/upgrade.3.2/set_flags.html
+++ /dev/null
@@ -1,35 +0,0 @@
-
-
-
-
-
- A new method has been added to the Berkeley DB environment handle,
-DBENV->set_flags. This interface currently takes three flags:
-DB_CDB_ALLDB, DB_NOMMAP and DB_TXN_NOSYNC. The
-first of these flags, DB_CDB_ALLDB, provides new functionality,
-allowing Berkeley DB Concurrent Data Store applications to do locking across multiple databases.
- The other two flags, DB_NOMMAP and DB_TXN_NOSYNC, were
-specified to the DBENV->open method in previous releases. In
-the 3.2 release, they have been moved to the DBENV->set_flags function
-because this allows the database environment's value to be toggled
-during the life of the application as well as because it is a more
-appropriate place for them. Applications specifying either the
-DB_NOMMAP or DB_TXN_NOSYNC flags to the
-DBENV->open function should replace those flags with calls to the
-DBENV->set_flags function.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/toc.html b/bdb/docs/ref/upgrade.3.2/toc.html
deleted file mode 100644
index 8a466d1b4d3..00000000000
--- a/bdb/docs/ref/upgrade.3.2/toc.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade.3.2/tx_recover.html b/bdb/docs/ref/upgrade.3.2/tx_recover.html
deleted file mode 100644
index c5cf18ebcfb..00000000000
--- a/bdb/docs/ref/upgrade.3.2/tx_recover.html
+++ /dev/null
@@ -1,32 +0,0 @@
-
-
-
-
-
- The info parameter of the function passed to
-DBENV->set_tx_recover is no longer needed. If your application
-calls DBENV->set_tx_recover, find the callback function referenced
-in that call and remove the info parameter.
- In addition, the called function no longer needs to handle Berkeley DB log
-records, Berkeley DB will handle them internally as well as call the
-application-specified function. Any handling of Berkeley DB log records in the
-application's callback function may be removed.
- In addition, the callback function will no longer be called with the
-DB_TXN_FORWARD_ROLL flag specified unless the transaction
-enclosing the operation successfully committed.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/upgrade/process.html b/bdb/docs/ref/upgrade/process.html
deleted file mode 100644
index 40be3c8e898..00000000000
--- a/bdb/docs/ref/upgrade/process.html
+++ /dev/null
@@ -1,108 +0,0 @@
-
-
-
-
-
- The following information describes the general process of upgrading
-Berkeley DB installations. There are three issues to be considered when
-upgrading Berkeley DB applications and database environments. They are the
-application API, the underlying database formats, and, in the case of
-transactional database environments, the log files.
- An application must always be re-compiled to use a new Berkeley DB release.
-Internal Berkeley DB interfaces may change at any time and in any release,
-without warning. This means the application and library must be entirely
-recompiled and reinstalled when upgrading to new releases of the
-library, as there is no guarantee that modules from one version of the
-library will interact correctly with modules from another release.
- A Berkeley DB patch release will never modify the Berkeley DB API, log file or
-database formats in non-backward compatible ways. Berkeley DB minor and major
-releases may optionally include changes to the Berkeley DB application API,
-log files and database formats that are not backward compatible. Note,
-that there are several underlying Berkeley DB database formats. As all of
-them do not necessarily change at the same time, changes to one database
-format in a release may not affect any particular application.
- Each Berkeley DB minor or major release has an upgrading section in this
-chapter of the Berkeley DB Reference Guide. The section describes any API
-changes that were made in the release. Application maintainers must
-review the API changes, update their applications as necessary, and then
-re-compile using the new release. In addition, each section includes
-a page specifying if the log file format or database formats changed in
-non-backward compatible ways as part of the release.
- If the application does not have a Berkeley DB transactional environment, the
-re-compiled application may be installed in the field using the
-following steps:
- If the application has a Berkeley DB transactional environment, but neither
-the log file or database formats have changed, the re-compiled
-application may be installed in the field using the following steps:
- If the application has a Berkeley DB transactional environment, and the log
-file format has changed but the database formats have not, the
-re-compiled application may be installed in the field using the
-following steps:
- If the application has a Berkeley DB transactional environment and the
-database format has changed, the re-compiled application may be
-installed in the field using the following steps:
- This archival is not strictly necessary. However, if you have to perform
-catastrophic recovery after restarting your applications, that recovery
-must be done based on the last archive you have made. If you make this
-archive, you can use it as the basis of your catastrophic recovery. If
-you do not make this archive, you will have to use the archive you made
-in step #2 as the basis of your recovery, and you will have to upgrade it
-as described in step #3 before you can apply your log files to it.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/xa/config.html b/bdb/docs/ref/xa/config.html
deleted file mode 100644
index cfe31f372f4..00000000000
--- a/bdb/docs/ref/xa/config.html
+++ /dev/null
@@ -1,79 +0,0 @@
-
-
-
-
-
- This information assumes that you have already installed the Berkeley DB
-library.
- First, you must update the resource manager file in Tuxedo. For the
-purposes of this discussion, assume the Tuxedo home directory is in:
- where ${DB_INSTALLHOME} is the directory into which you installed the Berkeley DB
-library.
- Note, the above load options are for a Sun Microsystems Solaris
-5.6 Sparc installation of Tuxedo, and may not be correct for your system.
- Next, you must build the transaction manager server. To do this, use the
-Tuxedo buildtms(1) utility. The buildtms utility will create
-the Berkeley-DB resource manager in the directory from which it was run.
-The parameters to buildtms should be:
- This will create an executable transaction manager server, DBRM, that is
-called by Tuxedo to process begins, commits, and aborts.
- Finally, you must make sure that your TUXCONFIG environment variable
-identifies a ubbconfig file that properly identifies your resource
-managers. In the GROUPS section of the ubb file, you should identify the
-group's LMID and GRPNO as well as the transaction manager server name
-"TMSNAME=DBRM." You must also specify the OPENINFO parameter, setting it
-equal to the string:
- where rm_name is the resource name specified in the RM file (i.e.,
-BERKELEY-DB) and dir is the directory for the Berkeley DB home environment
-(see DBENV->open for a discussion of Berkeley DB environments).
- As Tuxedo resource manager startup accepts only a single string for
-configuration, any environment customization that might have been done
-via the config parameter to DBENV->open must instead be done by
-placing a DB_CONFIG file in the Berkeley DB environment directory. See
-Berkeley DB File Naming for further
-information.
- Consider the following configuration. We have built a transaction
-manager server as described above. We want the Berkeley DB environment
-to be /home/dbhome, our database files to be maintained
-in /home/datafiles, our log files to be maintained in
-/home/log, and we want a duplexed server.
- The GROUPS section of the ubb file might look like:
- There would be a DB_CONFIG configuration file in the directory
-/home/dbhome that contained the following two lines:
- Finally, the ubb file must be translated into a binary version, using
-Tuxedo's tmloadcf(1) utility, and then the pathname of that
-binary file must be specified as your TUXCONFIG environment variable.
- At this point, your system is properly initialized to use the Berkeley DB
-resource manager.
- See db_create for further information on accessing data files
-using XA.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/xa/faq.html b/bdb/docs/ref/xa/faq.html
deleted file mode 100644
index db1e26a0b6b..00000000000
--- a/bdb/docs/ref/xa/faq.html
+++ /dev/null
@@ -1,55 +0,0 @@
-
-
-
-
-
- When converting an application to run under XA, the application's Berkeley DB
-calls are unchanged, with two exceptions:
- Otherwise, your application should be unchanged.
- Yes. It is also possible for XA and non-XA transactions to co-exist in
-the same Berkeley DB environment. To do this, specify the same environment to
-the non-XA DBENV->open calls as was specified in the Tuxedo
-configuration file.
- When the Tuxedo recovery calls the Berkeley DB recovery functions, the standard
-Berkeley DB recovery procedures occur, for all operations that are represented
-in the Berkeley DB log files. This includes any non-XA transactions that were
-performed in the environment. Of course, this means that you can't use
-the standard Berkeley DB utilities (e.g., db_recover) to perform
-recovery.
- Also, standard log file archival and catastrophic recovery procedures
-should occur independently of XA operation.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/ref/xa/intro.html b/bdb/docs/ref/xa/intro.html
deleted file mode 100644
index 7643ee420c6..00000000000
--- a/bdb/docs/ref/xa/intro.html
+++ /dev/null
@@ -1,61 +0,0 @@
-
-
-
-
-
- Berkeley DB can be used as an XA-compliant resource manager. The XA
-implementation is known to work with the Tuxedo(tm) transaction
-manager.
- The XA support is encapsulated in the resource manager switch
-db_xa_switch, which defines the following functions:
- The Berkeley DB resource manager does not support the following optional
-XA features:
- The Tuxedo System is available from BEA Systems, Inc.
- For additional information on Tuxedo, see:
- For additional information on XA Resource Managers, see:
- For additional information on The Tuxedo System, see:
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/sleepycat/contact.html b/bdb/docs/sleepycat/contact.html
deleted file mode 100644
index c2d1e7f0ac7..00000000000
--- a/bdb/docs/sleepycat/contact.html
+++ /dev/null
@@ -1,107 +0,0 @@
-
-
-
-
-
- Copyright (c) 1990-2000 Sleepycat Software, Inc., 394 E. Riding Dr.,
-Carlisle, MA 01741-1601 U.S.A. All Rights Reserved.
- This product and publication is protected by copyright and distributed
-under licenses restricting its use, copying and distribution. Permission
-to use this publication or portions of this publication is granted by
-Sleepycat Software provided that the above copyright notice appears in
-all copies and that use of such publications is for non-commercial use
-only and no modifications of the publication is made.
- RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government
-is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR
-52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a).
- Sleepycat and the names of Sleepycat Software products referenced herein
-are either trademarks and/or service marks or registered trademarks and/or
-service marks of Sleepycat Software Inc.
- Sun Microsystems, SunOS and Solaris are trademarks or registered
-trademarks of Sun Microsystems, Inc.
- Hewlett-Packard and HP-UX are trademarks or registered trademarks of
-Hewlett-Packard Company.
- DIGITAL and ULTRIX are trademarks or registered trademarks of Digital
-Equipment Corporation.
- Microsoft, Windows and Windows NT are trademarks or registered trademarks
-of Microsoft Corporation.
- TUXEDO is a trademark or registered trademark of BEA Systems, Inc.
- All other brand, company and product names referenced in this publication
-may be trademarks, registered trademarks or service marks of their
-respective holders and are used here for informational purposes only.
- WARNING: There is a non-zero chance that, through a process know as
-"tunneling," this product may spontaneously disappear from its present
-location and reappear at any random place in the universe. Sleepycat
-Software will not be responsible for damages or inconvenience that may
-result.
- THIS PRODUCT IS PROVIDED BY SLEEPYCAT SOFTWARE "AS IS" AND ANY EXPRESS OR
-IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT,
-ARE DISCLAIMED. IN NO EVENT SHALL SLEEPYCAT SOFTWARE BE LIABLE FOR ANY
-DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
-(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/sleepycat/license.html b/bdb/docs/sleepycat/license.html
deleted file mode 100644
index 1407eed05ad..00000000000
--- a/bdb/docs/sleepycat/license.html
+++ /dev/null
@@ -1,109 +0,0 @@
-
-
-
-
- The following is the license that applies to this copy of the Berkeley DB
-software. For a license to use the Berkeley DB software under conditions
-other than those described here, or to purchase support for this software,
-please contact Sleepycat Software.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/berkeley_db_svc.html b/bdb/docs/utility/berkeley_db_svc.html
deleted file mode 100644
index 9e9c7bb4e45..00000000000
--- a/bdb/docs/utility/berkeley_db_svc.html
+++ /dev/null
@@ -1,88 +0,0 @@
-
-
-
-
- The berkeley_db_svc utility is the Berkeley DB RPC server.
- The options are as follows:
- Recovery will be run on each specified environment before the server
-begins accepting requests from clients. For this reason, only one copy
-of the server program should ever be run at any time, as recovery must
-always be single-threaded.
- The berkeley_db_svc utility uses a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, berkeley_db_svc should always be given the chance to detach from
-the environment and exit gracefully. To cause berkeley_db_svc to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The berkeley_db_svc utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_archive.html b/bdb/docs/utility/db_archive.html
deleted file mode 100644
index 5cc56a428b1..00000000000
--- a/bdb/docs/utility/db_archive.html
+++ /dev/null
@@ -1,85 +0,0 @@
-
-
-
-
- The db_archive utility writes the pathnames of log files that are
-no longer in use (e.g., no longer involved in active transactions), to
-the standard output, one pathname per line. These log files should be
-written to backup media to provide for recovery in the case of
-catastrophic failure (which also requires a snapshot of the database
-files), but they may then be deleted from the system to reclaim disk
-space.
- The options are as follows:
- It is possible that some of the files referenced in the log have since
-been deleted from the system.
-In this case, db_archive will ignore them.
-When db_recover is run, any files referenced in the log that
-are not present during recovery are assumed to have been deleted and will
-not be recovered.
- The db_archive utility uses a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_archive should always be given the chance to detach from
-the environment and exit gracefully. To cause db_archive to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_archive utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_checkpoint.html b/bdb/docs/utility/db_checkpoint.html
deleted file mode 100644
index dc49d03d8f5..00000000000
--- a/bdb/docs/utility/db_checkpoint.html
+++ /dev/null
@@ -1,82 +0,0 @@
-
-
-
-
- The db_checkpoint utility is a daemon process that monitors the
-database log and periodically calls txn_checkpoint to checkpoint it.
- The options are as follows:
- At least one of the -1, -k and -p options must
-be specified.
- The db_checkpoint utility uses a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_checkpoint should always be given the chance to detach from
-the environment and exit gracefully. To cause db_checkpoint to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_checkpoint utility does not attempt to create the Berkeley DB
-shared memory regions if they do not already exist. The application
-which creates the region should be started first, and then, once the
-region is created, the db_checkpoint utility should be started.
- The db_checkpoint utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_deadlock.html b/bdb/docs/utility/db_deadlock.html
deleted file mode 100644
index dfd23a903be..00000000000
--- a/bdb/docs/utility/db_deadlock.html
+++ /dev/null
@@ -1,85 +0,0 @@
-
-
-
-
- The db_deadlock utility traverses the database lock structures
-and aborts a lock request each time it detects a deadlock. By default,
-a random lock request is chosen to be aborted. This utility should be
-run as a background daemon, or the underlying Berkeley DB deadlock detection
-interfaces should be called in some other way, whenever there are
-multiple threads or processes accessing a database and at least one of
-them is modifying it.
- The options are as follows:
- At least one of the -t and -w options must be specified.
- The db_deadlock utility uses a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_deadlock should always be given the chance to detach from
-the environment and exit gracefully. To cause db_deadlock to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_deadlock utility does not attempt to create the Berkeley DB
-shared memory regions if they do not already exist. The application
-which creates the region should be started first, and then, once the
-region is created, the db_deadlock utility should be started.
- The db_deadlock utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_dump.html b/bdb/docs/utility/db_dump.html
deleted file mode 100644
index bd97b307c7b..00000000000
--- a/bdb/docs/utility/db_dump.html
+++ /dev/null
@@ -1,128 +0,0 @@
-
-
-
-
- The db_dump utility reads the database file file and
-writes it to the standard output using a portable flat-text format
-understood by the db_load utility. The argument file
-must be a file produced using the Berkeley DB library functions.
- The db_dump185 utility is similar to the db_dump utility
-except that it reads databases in the format used by Berkeley DB versions 1.85
-and 1.86.
- The options are as follows:
- The output format of the -d option is not standard and may change,
-without notice, between releases of the Berkeley DB library.
- Note, different systems may have different notions as to what characters
-are considered printing characters, and databases dumped in
-this manner may be less portable to external systems.
- Dumping and reloading Hash databases that use user-defined hash functions
-will result in new databases that use the default hash function.
-While using the default hash function may not be optimal for the new database,
-it will continue to work correctly.
- Dumping and reloading Btree databases that use user-defined prefix or
-comparison functions will result in new databases that use the default
-prefix and comparison functions.
-In this case, it is quite likely that the database will be damaged
-beyond repair permitting neither record storage or retrieval.
- The only available workaround for either case is to modify the sources
-for the db_load utility to load the database using the correct
-hash, prefix and comparison functions.
- The db_dump185 utility may not be available on your system as it
-is not always built when the Berkeley DB libraries and utilities are installed.
-If you are unable to find it, see your system administrator for further
-information.
- The db_dump and db_dump185 utility output formats are
-documented in the Dump Output
-Formats section of the Reference Guide.
- The db_dump utility may be used with a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_dump should always be given the chance to detach from
-the environment and exit gracefully. To cause db_dump to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- When using an Berkeley DB database environment, the db_dump utility
-does not configure for any kind of database locking and so should not
-be used with active Berkeley DB environments. If db_dump is used in
-an active database environment, corruption may result.
- The db_dump utility exits 0 on success, and >0 if an error occurs.
- The db_dump185 utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_load.html b/bdb/docs/utility/db_load.html
deleted file mode 100644
index 41084f09cd0..00000000000
--- a/bdb/docs/utility/db_load.html
+++ /dev/null
@@ -1,151 +0,0 @@
-
-
-
-
- The db_load utility reads from the standard input and loads it
-into the database file. The database file is created if
-it does not already exist.
- The input to db_load must be in the output format specified by the
-db_dump utility, utilities, or as specified for the -T
-below.
- The options are as follows:
- If a home directory is specified, the database environment is opened using
-the DB_INIT_LOCK, DB_INIT_LOG, DB_INIT_MPOOL,
-DB_INIT_TXN and DB_USE_ENVIRON flags to
-DBENV->open. (This means that db_load can be used to load
-data into databases while they are in use by other processes.) If the
-DBENV->open call fails, or if no home directory is specified, the
-database is still updated, but the environment is ignored, e.g., no
-locking is done.
- If the database to be created is of type Btree or Hash, or the keyword
-keys is specified as set, the input must be paired lines of text,
-where the first line of the pair is the key item, and the second line of
-the pair is its corresponding data item. If the database to be created
-is of type Queue or Recno and the keywork keys is not set, the
-input must be lines of text, where each line is a new data item for the
-database.
- A simple escape mechanism, where newline and backslash (\)
-characters are special, is applied to the text input. Newline characters
-are interpreted as record separators. Backslash characters in the text
-will be interpreted in one of two ways: if the backslash character
-precedes another backslash character, the pair will be interpreted as a
-literal backslash. If the backslash character precedes any other
-character, the two characters following the backslash will be interpreted
-as hexadecimal specification of a single character, e.g., \0a
-is a newline character in the ASCII character set.
- For this reason, any backslash or newline characters that naturally
-occur in the text input must be escaped to avoid misinterpretation by
-db_load.
- If the -T option is specified, the underlying access method type
-must be specified using the -t option.
- Btree and Hash databases may be converted from one to the other. Queue
-and Recno databases may be converted from one to the other. If the
--k option was specified on the call to db_dump then Queue
-and Recno databases may be converted to Btree or Hash, with the key being
-the integer record number.
- The db_load utility may be used with a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_load should always be given the chance to detach from
-the environment and exit gracefully. To cause db_load to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_load utility exits 0 on success, 1 if one or more key/data
-pairs were not loaded into the database because the key already existed,
-and >1 if an error occurs.
- The db_load utility can be used to load text files into databases.
-For example, the following command loads the standard UNIX
-/etc/passwd file into a database, with the login name as the
-key item and the entire password entry as the data item:
- Note that backslash characters naturally occurring in the text are escaped
-to avoid interpretation as escape characters by db_load.
- The parenthetical listing specifies how the value part of the
-name=value pair is interpreted. Items listed as (boolean) expect
-value to be 1 (set) or 0 (unset). Items listed as
-(number) convert value to a number. Items listed as (string) use the
-string value without modification.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_printlog.html b/bdb/docs/utility/db_printlog.html
deleted file mode 100644
index 10033e09483..00000000000
--- a/bdb/docs/utility/db_printlog.html
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
-
-
- The db_printlog utility is a debugging utility that dumps Berkeley DB
-log files in a human-readable format.
- The options are as follows:
- For more information on the db_printlog output and using it to
-debug applications, see Reviewing
-Berkeley DB log files.
- The db_printlog utility uses a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_printlog should always be given the chance to detach from
-the environment and exit gracefully. To cause db_printlog to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_printlog utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_recover.html b/bdb/docs/utility/db_recover.html
deleted file mode 100644
index 80341597cd7..00000000000
--- a/bdb/docs/utility/db_recover.html
+++ /dev/null
@@ -1,97 +0,0 @@
-
-
-
-
- The db_recover utility must be run after an unexpected application,
-Berkeley DB, or system failure to restore the database to a consistent state.
-All committed transactions are guaranteed to appear after db_recover
-has run, and all uncommitted transactions will be completely undone.
- The options are as follows:
- If the "CC" and "YY" letter pairs are not specified, the values default
-to the current year. If the "SS" letter pair is not specified, the value
-defaults to 0.
- In the case of catastrophic recovery, an archival copy, or
-snapshot of all database files must be restored along with all
-of the log files written since the database file snapshot was made. (If
-disk space is a problem, log files may be referenced by symbolic links).
-For further information on creating a database snapshot, see
-Archival Procedures.
-For further information on performing recovery, see
-Recovery Procedures.
- If the failure was not catastrophic, the files present on the system at the
-time of failure are sufficient to perform recovery.
- If log files are missing, db_recover will identify the missing
-log file(s) and fail, in which case the missing log files need to be
-restored and recovery performed again.
- The db_recover utility uses a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_recover should always be given the chance to detach from
-the environment and exit gracefully. To cause db_recover to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_recover utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_stat.html b/bdb/docs/utility/db_stat.html
deleted file mode 100644
index ba9263e3221..00000000000
--- a/bdb/docs/utility/db_stat.html
+++ /dev/null
@@ -1,104 +0,0 @@
-
-
-
-
- The db_stat utility displays statistics for Berkeley DB environments.
- The options are as follows:
- If the database contains multiple databases and the -s flag is
-not specified, the statistics are for the internal database that describes
-the other databases the file contains, and not for the file as a whole.
- Only one set of statistics is displayed for each run, and the last option
-specifying a set of statistics takes precedence.
- Values smaller than 10 million are generally displayed without any special
-notation. Values larger than 10 million are normally displayed as
-<number>M.
- The db_stat utility may be used with a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_stat should always be given the chance to detach from
-the environment and exit gracefully. To cause db_stat to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_stat utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_upgrade.html b/bdb/docs/utility/db_upgrade.html
deleted file mode 100644
index 6375f380ed9..00000000000
--- a/bdb/docs/utility/db_upgrade.html
+++ /dev/null
@@ -1,93 +0,0 @@
-
-
-
-
- The db_upgrade utility upgrades the Berkeley DB version of one or more
-files and the databases they contain to the current release version.
- The options are as follows:
- As part of the upgrade from the Berkeley DB 3.0 release to the 3.1 release, the
-on-disk format of duplicate data items changed. To correctly upgrade the
-format requires applications specify if duplicate data items in the
-database are sorted or not. Specifying the -s flag means that
-the duplicates are sorted, otherwise they are assumed to be unsorted.
-Incorrectly specifying the value of this flag may lead to database
-corruption.
- Because the db_upgrade utility upgrades a physical file (including
-all of the databases it contains), it is not possible to use
-db_upgrade to upgrade files where some of the databases it
-includes have sorted duplicate data items and some of the databases it
-includes have unsorted duplicate data items. If the file does not have
-more than a single database, or the databases do not support duplicate
-data items, or all of the databases that support duplicate data items
-support the same style of duplicates (either sorted or unsorted),
-db_upgrade will work correctly as long as the -s flag is
-correctly specified. Otherwise, the file cannot be upgraded using
-db_upgrade, and must be upgraded manually using the db_dump
-and db_load utilities.
- It is important to realize that Berkeley DB database upgrades are done
-in place, and so are potentially destructive. This means that if the
-system crashes during the upgrade procedure, or if the upgrade procedure
-runs out of disk space, the databases may be left in an inconsistent and
-unrecoverable state. See Upgrading
-databases for more information.
- The db_upgrade utility may be used with a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_upgrade should always be given the chance to detach from
-the environment and exit gracefully. To cause db_upgrade to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_upgrade utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/db_verify.html b/bdb/docs/utility/db_verify.html
deleted file mode 100644
index 610e857a9da..00000000000
--- a/bdb/docs/utility/db_verify.html
+++ /dev/null
@@ -1,73 +0,0 @@
-
-
-
-
- The db_verify utility verifies the structure of one or more
-files and the databases they contain.
- The options are as follows:
- If the file being verified contains databases using non-default
-comparison or hashing functions, the db_verify utility may
-not be used for verification, as it will likely always return failure.
-Such files must be verified explicitly, using the DB->verify function,
-after setting the correct comparison or hashing functions.
- The db_verify utility may be used with a Berkeley DB environment (as described for the
--h option, the environment variable DB_HOME, or,
-because the utility was run in a directory containing a Berkeley DB
-environment). In order to avoid environment corruption when using a Berkeley DB
-environment, db_verify should always be given the chance to detach from
-the environment and exit gracefully. To cause db_verify to release all
-environment resources and exit cleanly, send it an interrupt signal
-(SIGINT).
- The db_verify utility exits 0 on success, and >0 if an error occurs.
- Copyright Sleepycat Software
-
-
diff --git a/bdb/docs/utility/index.html b/bdb/docs/utility/index.html
deleted file mode 100644
index 3f0c430ab0f..00000000000
--- a/bdb/docs/utility/index.html
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
- Copyright Sleepycat Software
-
-
diff --git a/mit-pthreads/Changes-mysql b/mit-pthreads/Changes-mysql
index 420434db98f..da30f66fdec 100644
--- a/mit-pthreads/Changes-mysql
+++ b/mit-pthreads/Changes-mysql
@@ -1,5 +1,9 @@
Changes done to this distrubtion (pthreads-1_60_beta6) by Monty (monty@mysql.com)
+02.05.07
+- Hacked some files to get it to compile (not work) with glibc 2.2
+ This is needed so that we can do 'make dist' in the MySQL distribution
+
02.04.26
- removed the following files because of copyright problems
diff --git a/mit-pthreads/GNUmakefile b/mit-pthreads/GNUmakefile
index a36f425c7a7..e3fd53b48e5 100644
--- a/mit-pthreads/GNUmakefile
+++ b/mit-pthreads/GNUmakefile
@@ -19,7 +19,7 @@ INSTALL_PATH = $(exec_prefix)
AR = ar
AS = gas
CFLAGS = -I. -Iinclude -I$(srcdir)/include -DPTHREAD_KERNEL \
- -O6 -DDBUG_OFF -Werror
+ -O3 -DDBUG_OFF -Werror
CXXFLAGS = -I. -Iinclude -I$(srcdir)/include -DPTHREAD_KERNEL \
-g -O2
LD = gld
diff --git a/mit-pthreads/include/pthread/ac-types.h b/mit-pthreads/include/pthread/ac-types.h
index 0a13d320e88..7fa4568817f 100644
--- a/mit-pthreads/include/pthread/ac-types.h
+++ b/mit-pthreads/include/pthread/ac-types.h
@@ -1,11 +1,10 @@
#ifndef pthread_size_t
-#define pthread_ipaddr_type unsigned int
+#define pthread_ipaddr_type unsigned long
#define pthread_ipport_type unsigned short
#define pthread_clock_t long
#define pthread_size_t unsigned int
#define pthread_ssize_t int
#define pthread_time_t long
-#define pthread_fpos_t long
#define pthread_off_t long
#define pthread_va_list void *
#endif
diff --git a/mit-pthreads/include/pthread/paths.h b/mit-pthreads/include/pthread/paths.h
index 8af9233a67c..bf2bf9d01a2 100644
--- a/mit-pthreads/include/pthread/paths.h
+++ b/mit-pthreads/include/pthread/paths.h
@@ -1,8 +1,8 @@
#ifndef _SYS___PATHS_H_
#define _SYS___PATHS_H_
#define _PATH_PTY "/dev/"
-#define _PATH_TZDIR "/usr/share/zoneinfo"
-#define _PATH_TZFILE "/etc/localtime"
+#define _PATH_TZDIR "/usr/lib/zoneinfo"
+#define _PATH_TZFILE "/usr/lib/zoneinfo/localtime"
#define _PATH_RESCONF "/etc/resolv.conf"
#define _PATH_HOSTS "/etc/hosts"
#define _PATH_NETWORKS "/etc/networks"
diff --git a/mit-pthreads/machdep/engine-i386-linux-2.0.h b/mit-pthreads/machdep/engine-i386-linux-2.0.h
index 721618a6f19..f4f75621226 100644
--- a/mit-pthreads/machdep/engine-i386-linux-2.0.h
+++ b/mit-pthreads/machdep/engine-i386-linux-2.0.h
@@ -4,6 +4,7 @@
* $Id$
*/
+/* Avoid problem with including bits/pthreadtypes.h with libc 2.2 */
#include 
-
-
-Berkeley DB
-
-
-
- Interface Documentation
- Building Berkeley DB
-
-
- C API
- C API Index
-
- C++ API Index
-
- Java API Index
-
-
- Building for UNIX and QNX systems
-
-
-
-
- Additional Documentation
- Company and Product Information
-
-
-
-
- Supporting Utilities
-
- Contacting Sleepycat Software
-
- Commercial Product List
- License
- Release Patches and Change Logs
- Sleepycat Software Home Page
-
-Copyright 1997-2000 Sleepycat Software, Inc. All Rights Reserved
-
-
-
-Legal Notices
-
-
-
diff --git a/bdb/docs/ref/am/close.html b/bdb/docs/ref/am/close.html
deleted file mode 100644
index 04b8beacb6a..00000000000
--- a/bdb/docs/ref/am/close.html
+++ /dev/null
@@ -1,43 +0,0 @@
-
-
-
-
-
-
-
- 
-Closing a database
-
-
-It is important to understand that flushing cached information
-to disk only minimizes the window of opportunity for corrupted data, it
-does not eliminate the possibility.
-
-
-
-
-
-
- Data item count
-
-
-
-
- Closing a cursor
-
-
-
-
- Deleting records with a cursor
-
-
-
-
- Duplicating a cursor
-
-
-
-
- Retrieving records with a cursor
-Cursor position flags
-
-
-Retrieving specific key/data pairs
-
-
-Retrieving based on record numbers
-
-
-Special-purpose flags
-
-
-
-
-
-
- Storing records with a cursor
-
-
-
-
-
-
- Database cursors
-
-
-
-
-
-
- Deleting records
-
-
-
-
- Error support
-
-int ret;
-if ((ret = dbp->put(dbp, NULL, &key, &data, 0)) != 0) {
- fprintf(stderr, "put failed: %s\n", db_strerror(ret));
- return (1);
-}
-
-#define DATABASE "access.db"
-int ret;
-dbp->errpfx(dbp, argv0);
-if ((ret =
- dbp->open(dbp, DATABASE, DB_BTREE, DB_CREATE, 0664)) != 0) {
- dbp->err(dbp, ret, "%s", DATABASE);
- dbp->errx(dbp,
- "contact your system administrator: session ID was %d",
- session_id);
- return (1);
-}
-
-my_app: access.db: Permission denied.
-my_app: contact your system administrator: session ID was 14
-
-
-
- Retrieving records
-
-
-
-
-
-
- Logical join
-
-Primary key: Primary data:
-apple Convenience Store
-blueberry Farmer's Market
-peach Shopway
-pear Farmer's Market
-raspberry Shopway
-strawberry Farmer's Market
-Secondary key: Secondary data:
-blue blueberry
-red apple
-red raspberry
-red strawberry
-yellow peach
-yellow pear
-
-
-Secondary key: Secondary data:
-expensive blueberry
-expensive peach
-expensive pear
-expensive strawberry
-inexpensive apple
-inexpensive pear
-inexpensive raspberry
Example
-
-
-
-
-
-
-
-
-
-Return the personnel records of all people named smith with the job
-title manager.
-DBC *name_curs, *job_curs, *join_curs;
-DBC *carray[3];
-DBT key, data;
-int ret, tret;
-
-
-
-
- Opening a database
-
-
-
-
-
-
-
-
- Opening multiple databases in a single file
-
-
-
-
- Access method operations
-
-
-
-
-
-
- Partial record storage and retrieval
-
-
-
-size = 20
-doff = 0
-dlen = 20
-data = abcdefghijabcdefghij
-
-size = 10
-doff = 20
-dlen = 0
-data = abcdefghij
-
-size = 10
-doff = 10
-dlen = 5
-data = abcdefghij
-
-size = 10
-doff = 10
-dlen = 0
-data = abcdefghij
-
-size = 10
-doff = 2
-dlen = 15
-data = abcdefghij
-
-size = 10
-doff = 0
-dlen = 0
-data = abcdefghij
-
-size = 0
-doff = 0
-dlen = 10
-data = ""
-
-size = 10
-doff = 25
-dlen = 0
-data = abcdefghij
-
-
-
-
- Storing records
-
-
-
-
-
-
- Cursor Stability
-
-
-
-
- Database statistics
-
-
-
-
-
-
- Flushing the database cache
-
-
-
-
-
-
- Upgrading databases
-
-
-
-
- Database verification and salvage
-
-
-
-
-
-
- Btree comparison
-
-int
-compare_int(dbp, a, b)
- DB *dbp;
- const DBT *a, *b;
-{
- int ai, bi;
-
-int
-compare_dbt(dbp, a, b)
- DB *dbp;
- const DBT *a, *b;
-{
- u_char *p1, *p2;
-
-
-
-
- Minimum keys per page
-
-maximum_size = page_size / (minimum_keys * 2)
-
-
-
- Btree prefix comparison
-
-u_int32_t
-compare_prefix(dbp, a, b)
- DB *dbp;
- const DBT *a, *b;
-{
- size_t cnt, len;
- u_int8_t *p1, *p2;
-
-
-
-
- Retrieving Btree records by number
-
-
-
-
- Selecting a byte order
-
-
-
-
- Selecting a cache size
-
-prompt: db_stat -m
-131072 Cache size (128K).
-4273 Requested pages found in the cache (97%).
-134 Requested pages not found in the cache.
-18 Pages created in the cache.
-116 Pages read into the cache.
-93 Pages written from the cache to the backing file.
-5 Clean pages forced from the cache.
-13 Dirty pages forced from the cache.
-0 Dirty buffers written by trickle-sync thread.
-130 Current clean buffer count.
-4 Current dirty buffer count.
-
-
-
-
- Duplicate data items
-
-
-
-
- Selecting a Queue extent size
-
-
-
-
- Page fill factor
-
-(pagesize - 32) / (average_key_size + average_data_size + 8)
-
-
-
- Specifying a database hash
-
-
-
-
- Hash table size
-
-
-
-
- What are the available access methods?
-Btree
-Hash
-Queue
-Recno
-
-
-
-
- Logical record numbers
-
-
-
-
- Non-local memory allocation
-
-
-
-
- Selecting a page size
-
-
-
-
- Flat-text backing files
-
-
-
-
- Managing record-based databases
-Record Delimiters
-Record Length
-Record Padding Byte Value
-
-
-
-
- Logically renumbering records
-
-
-
-
- Selecting an access method
-Hash or Btree?
-Queue or Recno?
-
-
-
-
- Programmatic APIs
-C
-
-#include <db.h>
C++
-
-#include <db_cxx.h>
JAVA
-Dbm/Ndbm, Hsearch
-
-
-
-
- The big picture
-
-switch (ret = dbp->put(dbp, NULL, &key, &data, 0)) {
-case 0:
- printf("db: %s: key stored.\n", (char *)key.data);
- break;
-default:
- dbp->err(dbp, ret, "dbp->put");
- exit (1);
-}
-
-retry: if ((ret = txn_begin(dbenv, NULL, &tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_begin");
- exit (1);
- }
-
-
-
-
-
-
-
- Programming model
-
-
-
-
- Scripting languages
-Perl
-Tcl
-
-
-
-
- Supporting utilities
-
-
-
-
-
-
- AIX
-
-
-
-xlc_r ...
-cc -D_THREAD_SAFE -lc_r ...
-
-
-#ifdef HAVE_FILE_OFFSET_BITS
-#define _LARGE_FILES /* AIX specific. */
-#endif
-
-
-
- Configuring Berkeley DB
-
-
-
-
-
-
-
- Changing compile or load options
-
-prompt: env CC=gcc ../dist/configure
-prompt: env CFLAGS=-O2 ../dist/configure
-prompt: env CPPFLAGS=-I/usr/contrib/include ../dist/configure
-prompt: env CXXFLAGS=-Woverloaded-virtual ../dist/configure
-prompt: env LDFLAGS="-N32 -L/usr/local/lib" ../dist/configure
-prompt: env LIBS="-lposix -lsocket" ../dist/configure
-prompt: LIBS="-lposix -lsocket" ../dist/configure
-prompt: setenv LIBS "-lposix -lsocket"
-prompt: ../dist/configure
-
-
-
- FreeBSD
-
-
-
-cc -D_THREAD_SAFE -pthread ...
-
-*** /usr/src/lib/libc/xdr/xdr_rec.c.orig Mon Jan 10 10:20:42 2000
---- /usr/src/lib/libc/xdr/xdr_rec.c Wed Jan 19 10:53:45 2000
-***************
-*** 558,564 ****
- * but we don't have any way to be certain that they aren't
- * what the client actually intended to send us.
- */
-! if ((header & (~LAST_FRAG)) == 0)
- return(FALSE);
- rstrm->fbtbc = header & (~LAST_FRAG);
- return (TRUE);
---- 558,564 ----
- * but we don't have any way to be certain that they aren't
- * what the client actually intended to send us.
- */
-! if (header == 0)
- return(FALSE);
- rstrm->fbtbc = header & (~LAST_FRAG);
- return (TRUE);
-
-
-
-
- HP-UX
-
-
-
-
-
-
-cc -D_REENTRANT ...
-
-
-#error "Large Files (ILP32) not supported in strict ANSI mode."
-
-
-chatr +s enable -l /full/path/to/libdb-3.2.sl ...
-
-
-
- Installing Berkeley DB
-
-
-Configuration Variables Default value --prefix /usr/local/BerkeleyDB.Major.Minor --exec_prefix $(prefix) --bindir $(exec_prefix)/bin --includedir $(prefix)/include --libdir $(exec_prefix)/lib docdir $(prefix)/docs Files Default location include files $(includedir) libraries $(libdir) utilities $(bindir) documentation $(docdir)
-prompt: ../dist/configure --bindir=/usr/local/bin
-prompt: make prefix=/usr/contrib/bdb install
-
-
-
- Building for UNIX
-
-../dist/configure
-make
-make install
-make clean
-make
-make realclean
-../dist/configure
-make
-mkdir build_bsdos3.0
-cd build_bsdos3.0
-../dist/configure
-make
-
-
-
- IRIX
-
-
-
-cc -D_SGI_MP_SOURCE ...
-
-
-
- Linux
-
-
-
-cc -D_REENTRANT ...
-
-
-
- Architecture independent FAQs
-
-
-
-symbol __muldi3: referenced symbol not found
-symbol __cmpdi2: referenced symbol not found
-
-
-cc ... -lpthread ...
-cc ... -lthread ...
-xlc_r ...
-cc ... -mt ...
-
-
-
-
-cc -o db_dump185 db_dump185.o
-ld:
-Unresolved:
-dbopen
-DB185INC=
-DB185LIB=
-DB185INC=/usr/local/include
-DB185LIB=-ldb185
-
-
-
- OSF/1
-
-
-
-cc -D_REENTRANT ...
-
-
-
- QNX
-
-
-
-
-
-
- SCO
-
-
-
-
-
-
- Dynamic shared libraries
-
-cc -L BUILD_DIRECTORY/.libs -o testprog testprog.o -ldb-3.5
-env LD_LIBRARY_PATH="BUILD_DIRECTORY/.libs:$LD_LIBRARY_PATH" ./testprog
-libtool gdb db_dump
-libtool --mode=execute my_debugger db_dump
-
-
-
- Solaris
-
-
-
-cc -mt ...
-cc -D_REENTRANT ... -lthread
-cc -D_REENTRANT ... -lpthread
-
-% which cc
-/usr/ucb/cc
-% cc
-/usr/ucb/cc: language optional software package not installed
-checking whether the C compiler (cc -O ) works... no
-configure: error: installation or configuration problem: C compiler cannot create executables.
-env CC=gcc ../dist/configure
-env CC=gcc CCC=g++ ../dist/configure
-
-
-Bug Id: 4291109
-Duplicate of: 4267207
-Category: library
-Subcategory: libthread
-State: closed
-Synopsis: pwrite64 mapped to pwrite
-Description:
-When libthread is linked after libc, there is a table of functions in
-libthread that gets "wired into" libc via _libc_threads_interface().
-The table in libthread is wrong in both Solaris 7 and on28_35 for the
-TI_PWRITE64 row (see near the end).
-
-
-
-
- SunOS
-
-
-
-
-
-
- Running the test suite under UNIX
-
-set tclsh_path ...
-set test_path ...
-% source ../test/test.tcl
-
-
-
- Ultrix
-
-
-
-
-
-
- VxWorks FAQ
-
-
-
-
-
-
- Building for VxWorks
-
-
-File Description
-Berkeley DB.wsp Berkeley DB Workspace file
-Berkeley DB.wpj Berkeley DB Project file
-ex_*/*.wpj Example programs project files Building With Tornado 2.0
-
-
-Build Description
-PENTIUM_RPCdebug x86 BSP with RPC and debugging
-PENTIUM_RPCnodebug x86 BSP with RPC no debugging
-PENTIUM_debug x86 BSP no RPC with debugging
-PENTIUM_nodebug x86 BSP no RPC no debugging
-SIMSPARCSOLARISgnu VxSim BSP no RPC with debugging
-
-
-
-
-
- VxWorks notes
-Building and Running the Example Programs
-
-
-Name Description
-ex_access Simple access method example.
-ex_btrec Example using Btree and record numbers.
-ex_dbclient Example running an RPC client. Takes a hostname as an argument, e.g.,
-ex_dbclient "myhost".
-ex_env Example using an environment.
-ex_mpool Example using mpools.
-ex_tpcb Example using transactions. This example requires two invocations both
-taking an integer identifier as an argument. This identifier allows for
-multiple sets of databases to be used within the same environment. The
-first is to initialize the databases, e.g., ex_tpcb_init 1. The
-second is to run the program on those databases, e.g., ex_tpcb 1.
-
-
-
- Windows FAQ
-
-
-
-
-
-
- Building for Win32
-
-
-Project File Description
-Berkeley_DB.dsw Visual C++ 5.0 project (compatible with 6.0)
-*.dsp Visual C++ 5.0 subprojects (compatible with 6.0
-) Building With Visual C++ 6.0
-Building With Visual C++ 5.0
-Including the C++ API
-Including the Java API
-
-java com.sleepycat.examples.AccessExample
Including the Tcl API
-
-
-
-
- Windows notes
-
-
-
-
-
-
- Running the test suite under Windows
-Building the software needed by the tests
-
-
-Running the test suite under Windows
-
-set tclsh_path SET_YOUR_TCLSH_PATH
-set tclsh_path d:/tcl/bin/tclsh83d.exe
-
-
-
-
-
- Building Berkeley DB Concurrent Data Store applications
-
-
-
-
-
-
- Common errors
-
-
-
-
-
-
-
-
- Compile-time configuration
-
-
-
-
-
-
- Introduction
-
-
-
-
-
-
- Reviewing Berkeley DB log files
-
-[22][28]db_big: rec: 43 txnid 80000963 prevlsn [21][10483281]
-
-
-Log Record Type Description bam_adj Used when we insert/remove an index into/from the page header of a Btree page. bam_cadjust Keeps track of record counts in a Btree or Recno database. bam_cdel Used to mark a record on a page as deleted. bam_curadj Used to adjust a cursor location when a nearby record changes in a Btree database. bam_pg_alloc Indicates that we allocated a page to a Btree. bam_pg_free Indicates that we freed a page in the Btree (freed pages are added to a freelist and reused). bam_rcuradj Used to adjust a cursor location when a nearby record changes in a Recno database. bam_repl Describes a replace operation on a record. bam_root Describes an assignment of a root page. bam_rsplit Describes a reverse page split. bam_split Describes a page split. crdel_delete Describes the removal of a Berkeley DB file. crdel_fileopen Describes a Berkeley DB file create attempt. crdel_metapage Describes the creation of a meta-data page for a new file. crdel_metasub Describes the creation of a meta data page for a subdatabase. crdel_rename Describes a file rename operation. db_addrem Add or remove an item from a page of duplicates. db_big Add an item to an overflow page (overflow pages contain items too large to place on the main page) db_debug Log debugging message. db_noop This marks an operation that did nothing but update the LSN on a page. db_ovref Increment or decrement the reference count for a big item. db_relink Fix prev/next chains on duplicate pages because a page was added or removed. ham_chgpg Used to adjust a cursor location when a Hash page is removed, and its elements are moved to a different Hash page. ham_copypage Used when we empty a bucket page, but there are overflow pages for the bucket; one needs to be copied back into the actual bucket. ham_curadj Used to adjust a cursor location when a nearby record changes in a Hash database. ham_groupalloc Allocate some number of contiguous pages to the Hash database. ham_insdel Insert/Delete an item on a Hash page. ham_metagroup Update the metadata page to reflect the allocation of a sequence of contiguous pages. ham_newpage Adds or removes overflow pages from a Hash bucket. ham_replace Handle updates to records that are on the main page. ham_splitdata Record the page data for a split. log_register Records an open of a file (mapping the file name to a log-id that is used in subsequent log operations). qam_add Describes the actual addition of a new record to a Queue. qam_del Delete a record in a Queue. qam_delete Remove a Queue extent file. qam_inc Increments the maximum record number allocated in a Queue indicating that we've allocated another space in the file. qam_incfirst Increments the record number that refers to the first record in the database. qam_mvptr Indicates that we changed the reference to either or both of the first and current records in the file. qam_rename Rename a Queue extent file. txn_child Commit a child transaction. txn_ckp Transaction checkpoint. txn_regop Logs a regular (non-child) transaction commit. txn_xa_regop Logs a prepare message. Augmenting the Log for Debugging
-Extracting Committed Transactions and Transaction Status
-
-where log_output is the output of db_printlog will display a list of
-the transaction IDs of all committed transactions found in the log.
-awk -f commit.awk log_output
-awk -f status.awk log_output
Extracting Transaction Histories
-
-where log_output is the output of db_printlog and txnlist is
-a comma-separated list of transaction IDs, will display all log records
-associated with the designated transaction ids.
-awk -f txn.awk TXN=txnlist log_output
Extracting File Histories
-
-awk -f fileid.awk PGNO=fids log_output
Extracting Page Histories
-
-awk -f pgno.awk PGNO=pgnolist log_output
Other log processing tools
-
-awk -f range.awk START_FILE=sf START_OFFSET=so END_FILE=ef END_OFFSET=eo log_output
-
-
-
- Run-time error information
-
-
-
-
- Source code layout
-
-
-Directory Description LICENSE Berkeley DB Copyright btree Btree access method source code. build_unix UNIX build directory. build_vxworks VxWorks build directory. build_win32 Windows build directory. clib C library replacement functions. common Common Berkeley DB functions. cxx C++ API. db Berkeley DB database interfaces. db185 Berkeley DB version 1.85 compatibility API db_archive The db_archive utility. db_checkpoint The db_checkpoint utility. db_deadlock The db_deadlock utility. db_dump The db_dump utility. db_dump185 The db_dump185 utility. db_load The db_load utility. db_printlog The db_printlog debugging utility. db_recover The db_recover utility. db_stat The db_stat utility. db_upgrade The db_upgrade utility. db_verify The db_verify utility. dbm The dbm/ndbm compatibility APIs. dist Berkeley DB administration/distribution tools. docs Documentation. env Berkeley DB environment interfaces. examples_c C API example programs. examples_cxx C++ API example programs. examples_java Java API example programs. hash Hash access method. hsearch The hsearch compatibility API. include Include files. java Java API. libdb_java The libdb_java shared library. lock Lock manager. log Log manager. mp Shared memory buffer pool. mutex Mutexes. os POSIX 1003.1 operating-system specific functionality. os_vxworks VxWorks operating-system specific functionality. os_win32 Windows operating-system specific functionality. perl.BerkeleyDB BerkeleyDB Perl module. perl.DB_File DB_File Perl module. qam Queue access method source code. rpc_client RPC client interface. rpc_server RPC server utility. tcl Tcl API. test Test suite. txn Transaction manager. xa X/Open Distributed Transaction Processing XA interface.
-
-
-
- Dump output formats
-
-
-
-
- Loading text into databases
-
-awk -F: '{print $1; print $0}' < /etc/passwd |\
- sed 's/\\/\\\\/g' | db_load -T -t hash passwd.db
-
-
-
- The db_dump and db_load utilities
-
-
-
-
- Creating an Environment
-
-
-
-
-
-
- Error support
-
-int ret;
-if ((ret = dbenv->set_cachesize(dbenv, 0, 32 * 1024)) != 0) {
- fprintf(stderr, "set_cachesize failed: %s\n", db_strerror(ret));
- return (1);
-}
-int ret;
-dbenv->set_errpfx(dbenv, argv0);
-if ((ret = dbenv->open(dbenv, home, NULL,
- DB_CREATE | DB_INIT_LOG | DB_INIT_TXN | DB_USE_ENVIRON))
- != 0) {
- dbenv->err(dbenv, ret, "open: %s", home);
- dbenv->errx(dbenv,
- "contact your system administrator: session ID was %d",
- session_id);
- return (1);
-}
-my_app: open: /tmp/home: Permission denied.
-my_app: contact your system administrator: session ID was 2
-
-
-
- Introduction
-
-
-
-
- File naming
-Specifying file naming to Berkeley DB
-
-
-
-env DB_HOME=/database/my_home application
File name resolution in Berkeley DB
-
-
-Examples
-Store all files in the directory /a/database:
-
-Create temporary backing files in /b/temporary, and all other files
-in /a/database:
-DBENV->open(DBENV, "/a/database", ...);
-Store data files in /a/database/datadir, log files in
-/a/database/logdir, and all other files in the directory
-/a/database:
-DBENV->set_tmp_dir(DBENV, "/b/temporary");
-DBENV->open(DBENV, "/a/database", ...);
-DBENV->set_lg_dir("logdir");
-DBENV->set_data_dir("datadir");
-DBENV->open(DBENV, "/a/database", ...);
-DBENV->set_data_dir(DBENV, "/b/data2");
-DBENV->set_data_dir(DBENV, "data1");
-DBENV->open(DBENV, "/a/database", ...);
-
-
-
- Opening databases within the environment
-
-
-
-
- Shared Memory Regions
-
-
-
-
-
-
- Remote filesystems
-
-
-
-
-
-
- Security
-
-
-
-
-
-
- File utility /etc/magic information
-
-
-
-
- An introduction to data management
-
-
-
-
- What is Berkeley DB?
-Data Access Services
-Data management services
-Design
-
-
-
-
- What is Berkeley DB not?
-
-
-Not a relational database
-Not an object-oriented database
-Not a network database
-Not a database server
-
-
-
-
- What does the Berkeley DB distribution include?
-
-
-
-
- Do you need Berkeley DB?
-
-
-
-
- Sleepycat Software's Berkeley DB products
-Berkeley DB Data Store
-Berkeley DB Concurrent Data Store
-Berkeley DB Transactional Data Store
-
-
-
-
- Mapping the terrain: theory and practice
-Data access and data management
-
-
-Relational databases
-Object-oriented databases
-Network databases
-Clients and servers
-
-
-
-
- What other services does Berkeley DB provide?
-
-
-
-
-
-
- Where does Berkeley DB run?
-
-
-
-
- Compatibility
-
-
-
-
- Configuration
-
- db-VERSION
- / \
- java libdb_java
- | |
- src ...
- |
- com
- |
- sleepycat
- / \
- db examples
- | |
- ... ...
-
-db-VERSION\build_win32\Release
-java.lang.UnsatisfiedLinkError
-java.lang.NoClassDefFoundError
-db-VERSION/java/src/com/sleepycat/examples
-% java com.sleepycat.examples.AccessExample
-
-
-
- Frequently Asked Questions
-
-
-
-
-
-
- Java Programming Notes
-
-
-
-
-
-
- Access method locking conventions
-
-
-
-
- Berkeley DB Concurrent Data Store locking conventions
-
-
-
-
-
-
-
-
- Configuring locking
-
-
-
-
-
-
- Deadlocks and deadlock avoidance
-
-
-
-
- Berkeley DB and locking
-
-
-
-
- Configuring locking: sizing the system
-
-DBENV->set_lk_max_locks
-DBENV->set_lk_max_lockers
-DBENV->set_lk_max_objects
-
-
-
-
-
-
-
- Locking and non-Berkeley DB applications
-
-
-
-
- Locking without transactions
-
-
-
-
- Page locks
-
-
-
-
- Standard lock modes
-
-
-
-
-
- Notheld Read Write
-Notheld 0 0 0
-Read* 0 0 1
-Write** 0 1 1
-
-
-
-
-
-
- Locking with transactions: two-phase locking
-
-
-
-
-
-
- Configuring logging
-
-
-
-
- Berkeley DB and logging
-
-
-
-
-
-
- Log file limits
-
-(10 * 2^20 * 2000000000) / (6000 * 500 * 365 * 60 * 60 * 24) = ~221
-
-
-
-
-
- Configuring the memory pool
-
-
-
-
- Berkeley DB and the memory pool
-
-
-
-
-
-
- Using Berkeley DB with Perl
-
-
-
-
- Application signal handling
-
-
-
-
- Byte ordering
-
-
-
-
- Compatibility with historic interfaces
-
-
-
-
- Copying databases
-
-
-
-
-
-
- Database limits
-
-
-
-
- Disk space requirements
-Btree
-
-useful-bytes-per-page = (page-size - page-overhead) * page-fill-factor
-
-6941 = (8192 - 26) * .85
-1560000000 = 60000000 * ((8 * 2) + (5 * 2))
-224751 = 1560000000 / 6941
-1841160192 = 224751 * 8192
Hash
-
-useful-bytes-per-page = (page-size - page-overhead)
-
-8166 = (8192 - 26)
-1320000000 = 60000000 * ((16 + 6))
-161646 = 1320000000 / 8166
-1324204032 = 161646 * 8192
-371 = 8166 / 22
-314 = 8166 / 26
-npages = npairs / pairs-per-page
-191082 = 60000000 / 314
-1565343744 = 191082 * 8192
-
-
-
- Environment variables
-
-
-
-
-
-
- Error returns to applications
-
-
-While possible error returns are specified by each individual function's
-manual page, there are a few error returns that deserve special mention:
-DB_NOTFOUND and DB_KEYEMPTY
-DB_LOCK_DEADLOCK
-DB_LOCK_NOTGRANTED
-DB_RUNRECOVERY
-
-
-
-
- Application-specific logging and recovery
-Defining Application-Specific Operations
-
-BEGIN RECORD_NAME RECORD_NUMBER
-END
-ARG | DBT | POINTER variable_name variable_type printf_format
Automatically Generated Functions
-
-
-
-One additional function, an initialization function,
-is created for each .src file.
-
-
-
-
-
-
-
-
-
-
-Using Automatically Generated Routines
-
-
-
-
-Non-conformant Logging
-
-
-
-
-
-
- Building multi-threaded applications
-
-
-
-
-
-
- Name spaces
-
-
-
-
- Recovery implementation
-
-
-
-
- Run-time configuration
-
-db_env_set_func_close
-db_env_set_func_dirfree
-db_env_set_func_dirlist
-db_env_set_func_exists
-db_env_set_func_free
-db_env_set_func_fsync
-db_env_set_func_ioinfo
-db_env_set_func_malloc
-db_env_set_func_map
-db_env_set_func_open
-db_env_set_func_read
-db_env_set_func_realloc
-db_env_set_func_seek
-db_env_set_func_sleep
-db_env_set_func_unlink
-db_env_set_func_unmap
-db_env_set_func_write
-db_env_set_func_yield
-DBENV->set_mutexlocks
-db_env_set_pageyield
-db_env_set_panicstate
-db_env_set_region_init
-db_env_set_tas_spins
-
-
-
- Berkeley DB handles
-
-
-
-
-
-
-
- Library version information
-
-
-
-Berkeley DB
-
-
-Keith Bostic
-
-Margo Seltzer
-
-
-Sleepycat Software, Inc.
-
-
-
-
-Abstract
-
-
-
-
-
-Introduction
-
-
-History
-
-
-Overview of Berkeley DB
-
-
-How Berkeley DB is used
-
-
-Applications that use Berkeley DB
-
-
-Access Methods
-
-
-Hash
-
-
-B+tree
-
-
-Recno
-
-
-Features
-
-
-Programmatic interfaces
-
-
-Working with records
-
-
-Long keys and values
-
-
-Large databases
-
-
-Main memory databases
-
-
-Configurable page size
-
-
-Small footprint
-
-
-Cursors
-
-
-Joins
-
-
-Transactions
-
-
-
-
-Write-ahead logging
-
-
-Crashes and recovery
-
-
-Checkpoints
-
-
-Two-phase locking
-
-
-Concurrency
-
-
-Engineering Philosophy
-
-
-The Berkeley DB 2.x Distribution
-
-
-What is in the distribution
-
-
-Documentation
-
-
-Test suite
-
-
-Binary distribution
-
-
-Supported platforms
-
-
-Berkeley DB 2.x Licensing
-
-
-
-
-Summary
-
-
-References
-
-
-
-
-
diff --git a/bdb/docs/ref/refs/bdb_usenix.ps b/bdb/docs/ref/refs/bdb_usenix.ps
deleted file mode 100644
index 82e6789719b..00000000000
--- a/bdb/docs/ref/refs/bdb_usenix.ps
+++ /dev/null
@@ -1,1441 +0,0 @@
-%!PS-Adobe-3.0
-%%Creator: groff version 1.11
-%%CreationDate: Mon Apr 26 13:38:12 1999
-%%DocumentNeededResources: font Times-Bold
-%%+ font Times-Roman
-%%+ font Times-Italic
-%%+ font Courier
-%%DocumentSuppliedResources: procset grops 1.11 0
-%%Pages: 9
-%%PageOrder: Ascend
-%%Orientation: Portrait
-%%EndComments
-%%BeginProlog
-%%BeginResource: procset grops 1.11 0
-/setpacking where{
-pop
-currentpacking
-true setpacking
-}if
-/grops 120 dict dup begin
-/SC 32 def
-/A/show load def
-/B{0 SC 3 -1 roll widthshow}bind def
-/C{0 exch ashow}bind def
-/D{0 exch 0 SC 5 2 roll awidthshow}bind def
-/E{0 rmoveto show}bind def
-/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def
-/G{0 rmoveto 0 exch ashow}bind def
-/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
-/I{0 exch rmoveto show}bind def
-/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def
-/K{0 exch rmoveto 0 exch ashow}bind def
-/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
-/M{rmoveto show}bind def
-/N{rmoveto 0 SC 3 -1 roll widthshow}bind def
-/O{rmoveto 0 exch ashow}bind def
-/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
-/Q{moveto show}bind def
-/R{moveto 0 SC 3 -1 roll widthshow}bind def
-/S{moveto 0 exch ashow}bind def
-/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def
-/SF{
-findfont exch
-[exch dup 0 exch 0 exch neg 0 0]makefont
-dup setfont
-[exch/setfont cvx]cvx bind def
-}bind def
-/MF{
-findfont
-[5 2 roll
-0 3 1 roll
-neg 0 0]makefont
-dup setfont
-[exch/setfont cvx]cvx bind def
-}bind def
-/level0 0 def
-/RES 0 def
-/PL 0 def
-/LS 0 def
-/MANUAL{
-statusdict begin/manualfeed true store end
-}bind def
-/PLG{
-gsave newpath clippath pathbbox grestore
-exch pop add exch pop
-}bind def
-/BP{
-/level0 save def
-1 setlinecap
-1 setlinejoin
-72 RES div dup scale
-LS{
-90 rotate
-}{
-0 PL translate
-}ifelse
-1 -1 scale
-}bind def
-/EP{
-level0 restore
-showpage
-}bind def
-/DA{
-newpath arcn stroke
-}bind def
-/SN{
-transform
-.25 sub exch .25 sub exch
-round .25 add exch round .25 add exch
-itransform
-}bind def
-/DL{
-SN
-moveto
-SN
-lineto stroke
-}bind def
-/DC{
-newpath 0 360 arc closepath
-}bind def
-/TM matrix def
-/DE{
-TM currentmatrix pop
-translate scale newpath 0 0 .5 0 360 arc closepath
-TM setmatrix
-}bind def
-/RC/rcurveto load def
-/RL/rlineto load def
-/ST/stroke load def
-/MT/moveto load def
-/CL/closepath load def
-/FL{
-currentgray exch setgray fill setgray
-}bind def
-/BL/fill load def
-/LW/setlinewidth load def
-/RE{
-findfont
-dup maxlength 1 index/FontName known not{1 add}if dict begin
-{
-1 index/FID ne{def}{pop pop}ifelse
-}forall
-/Encoding exch def
-dup/FontName exch def
-currentdict end definefont pop
-}bind def
-/DEFS 0 def
-/EBEGIN{
-moveto
-DEFS begin
-}bind def
-/EEND/end load def
-/CNT 0 def
-/level1 0 def
-/PBEGIN{
-/level1 save def
-translate
-div 3 1 roll div exch scale
-neg exch neg exch translate
-0 setgray
-0 setlinecap
-1 setlinewidth
-0 setlinejoin
-10 setmiterlimit
-[]0 setdash
-/setstrokeadjust where{
-pop
-false setstrokeadjust
-}if
-/setoverprint where{
-pop
-false setoverprint
-}if
-newpath
-/CNT countdictstack def
-userdict begin
-/showpage{}def
-}bind def
-/PEND{
-clear
-countdictstack CNT sub{end}repeat
-level1 restore
-}bind def
-end def
-/setpacking where{
-pop
-setpacking
-}if
-%%EndResource
-%%IncludeResource: font Times-Bold
-%%IncludeResource: font Times-Roman
-%%IncludeResource: font Times-Italic
-%%IncludeResource: font Courier
-grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72
-def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron
-/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef
-/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
-/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
-/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent
-/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen
-/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon
-/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O
-/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex
-/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y
-/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft
-/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl
-/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut
-/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash
-/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen
-/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft
-/logicalnot/minus/registered/macron/degree/plusminus/twosuperior
-/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior
-/ordmasculine/guilsinglright/onequarter/onehalf/threequarters
-/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE
-/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
-/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
-/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn
-/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
-/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
-/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash
-/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def
-/Courier@0 ENC0/Courier RE/Times-Italic@0 ENC0/Times-Italic RE
-/Times-Roman@0 ENC0/Times-Roman RE/Times-Bold@0 ENC0/Times-Bold RE
-%%EndProlog
-%%Page: 1 1
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 14/Times-Bold@0 SF(Berk)275.358 100.8 Q(eley DB)-.14 E/F1 12
-/Times-Roman@0 SF(Michael A. Olson)270.372 129.6 Q -.3(Ke)283.182 144 S
-(ith Bostic).3 E(Mar)279.15 158.4 Q(go Seltzer)-.216 E/F2 12
-/Times-Italic@0 SF(Sleepycat Softwar)255.492 174.24 Q .24 -.12(e, I)
--.444 H(nc.).12 E/F3 12/Times-Bold@0 SF(Abstract)290.874 210.24 Q/F4 10
-/Times-Roman@0 SF(Berk)79.2 226.44 Q(ele)-.1 E 2.925(yD)-.15 G 2.925(Bi)
--2.925 G 2.924(sa)-2.925 G 2.924(nO)-2.924 G .424
-(pen Source embedded database system with a number of k)-2.924 F .724
--.15(ey a)-.1 H(dv).15 E .424(antages o)-.25 F -.15(ve)-.15 G 2.924(rc)
-.15 G .424(omparable sys-)-2.924 F 3.102(tems. It)79.2 238.44 R .602(is simple to use, supports concurrent access by multiple users, and pro)
-3.102 F .602(vides industrial-strength transaction)-.15 F 1.555
-(support, including survi)79.2 250.44 R 1.555
-(ving system and disk crashes.)-.25 F 1.554
-(This paper describes the design and technical features of)6.555 F(Berk)
-79.2 262.44 Q(ele)-.1 E 2.5(yD)-.15 G(B, the distrib)-2.5 E
-(ution, and its license.)-.2 E F3 3(1. Intr)79.2 286.44 R(oduction)-.216
-E F4 .691(The Berk)79.2 302.64 R(ele)-.1 E 3.191(yD)-.15 G .691
-(atabase \(Berk)-3.191 F(ele)-.1 E 3.191(yD)-.15 G .692
-(B\) is an embedded)-3.191 F .253
-(database system that can be used in applications requir)79.2 314.64 R
-(-)-.2 E 1.636(ing high-performance concurrent storage and retrie)79.2
-326.64 R -.25(va)-.25 G(l).25 E 2.619(of k)79.2 338.64 R -.15(ey)-.1 G
-(/v).15 E 2.619(alue pairs.)-.25 F 2.619(The softw)7.619 F 2.619
-(are is distrib)-.1 F 2.618(uted as a)-.2 F .057
-(library that can be link)79.2 350.64 R .058
-(ed directly into an application.)-.1 F(It)5.058 E(pro)79.2 362.64 Q
-1.454(vides a v)-.15 F 1.453(ariety of programmatic interf)-.25 F 1.453
-(aces, includ-)-.1 F .237
-(ing callable APIs for C, C++, Perl, Tcl and Ja)79.2 374.64 R -.25(va)
--.2 G 5.237(.U).25 G(sers)-5.237 E .327(may do)79.2 386.64 R .327
-(wnload Berk)-.25 F(ele)-.1 E 2.827(yD)-.15 G 2.827(Bf)-2.827 G .326
-(rom Sleep)-2.827 F .326(ycat Softw)-.1 F(are')-.1 E(s)-.55 E -.8(We)
-79.2 398.64 S 2.5(bs).8 G(ite, at)-2.5 E/F5 10/Times-Italic@0 SF(www)2.5
-E(.sleepycat.com)-.74 E F4(.)A(Sleep)79.2 414.84 Q 1.33(ycat distrib)-.1
-F 1.33(utes Berk)-.2 F(ele)-.1 E 3.83(yD)-.15 G 3.83(Ba)-3.83 G 3.83(sa)
--3.83 G 3.83(nO)-3.83 G 1.33(pen Source)-3.83 F 3.3(product. The)79.2
-426.84 R(compan)3.3 E 3.3(yc)-.15 G .8(ollects license fees for certain)
--3.3 F(uses of the softw)79.2 438.84 Q
-(are and sells support and services.)-.1 E F3 3(1.1. History)79.2 468.84
-R F4(Berk)79.2 485.04 Q(ele)-.1 E 3.057(yD)-.15 G 3.057(Bb)-3.057 G
--2.25 -.15(eg a)-3.057 H 3.058(na).15 G 3.058(san)-3.058 G 1.058 -.25
-(ew i)-3.058 H .558(mplementation of a hash).25 F .843
-(access method to replace both)79.2 497.04 R/F6 10/Courier@0 SF(hsearch)
-3.342 E F4 .842(and the v)3.342 F(ari-)-.25 E(ous)79.2 509.04 Q F6(dbm)
-5.466 E F4 2.967(implementations \()5.466 F F6(dbm)A F4 2.967(from A)
-5.467 F(T&T)-1.11 E(,)-.74 E F6(ndbm)5.467 E F4 1.334(from Berk)79.2
-521.04 R(ele)-.1 E 2.634 -.65(y, a)-.15 H(nd).65 E F6(gdbm)3.834 E F4
-1.334(from the GNU project\).)3.834 F(In)6.333 E .367
-(1990 Seltzer and Y)79.2 533.04 R .368
-(igit produced a package called Hash)-.55 F(to do this [Selt91].)79.2
-545.04 Q 3.106(The \214rst general release of Berk)79.2 561.24 R(ele)-.1
-E 5.606(yD)-.15 G 3.106(B, in 1991,)-5.606 F 3.038(included some interf)
-79.2 573.24 R 3.039(ace changes and a ne)-.1 F 5.539(wB)-.25 G(+tree)
--5.539 E .887(access method.)79.2 585.24 R .886
-(At roughly the same time, Seltzer and)5.887 F 1.201(Olson de)79.2
-597.24 R -.15(ve)-.25 G 1.202
-(loped a prototype transaction system based).15 F 3.356(on Berk)79.2
-609.24 R(ele)-.1 E 5.856(yD)-.15 G 3.356(B, called LIBTP [Selt92], b)
--5.856 F 3.355(ut ne)-.2 F -.15(ve)-.25 G(r).15 E(released the code.)
-79.2 621.24 Q .653(The 4.4BSD UNIX release included Berk)79.2 637.44 R
-(ele)-.1 E 3.153(yD)-.15 G 3.153(B1)-3.153 G(.85)-3.153 E .602(in 1992.)
-79.2 649.44 R .601(Seltzer and Bostic maintained the code in the)5.601 F
-1.545(early 1990s in Berk)79.2 661.44 R(ele)-.1 E 4.046(ya)-.15 G 1.546
-(nd in Massachusetts.)-4.046 F(Man)6.546 E(y)-.15 E
-(users adopted the code during this period.)79.2 673.44 Q .432
-(By mid-1996, users w)79.2 689.64 R .431
-(anted commercial support for the)-.1 F(softw)79.2 701.64 Q 7.033
-(are. In)-.1 F 4.533(response, Bostic and Seltzer formed)7.033 F(Sleep)
-79.2 713.64 Q 10.128(ycat Softw)-.1 F 12.628(are. The)-.1 F(compan)
-12.627 E 15.127(ye)-.15 G(nhances,)-15.127 E(distrib)323.2 286.44 Q
-1.623(utes, and supports Berk)-.2 F(ele)-.1 E 4.123(yD)-.15 G 4.124(Ba)
--4.123 G 1.624(nd supporting)-4.124 F(softw)323.2 298.44 Q 2.2
-(are and documentation.)-.1 F(Sleep)7.2 E 2.2(ycat released v)-.1 F(er)
--.15 E(-)-.2 E 1.677(sion 2.1 of Berk)323.2 310.44 R(ele)-.1 E 4.177(yD)
--.15 G 4.178(Bi)-4.177 G 4.178(nm)-4.178 G 1.678(id-1997 with important)
--4.178 F(ne)323.2 322.44 Q 2.56(wf)-.25 G .06
-(eatures, including support for concurrent access to)-2.56 F 4.176
-(databases. The)323.2 334.44 R(compan)4.176 E 4.177(ym)-.15 G(ak)-4.177
-E 1.677(es about three commer)-.1 F(-)-.2 E .958(cial releases a year)
-323.2 346.44 R 3.458(,a)-.4 G .957(nd most recently shipped v)-3.458 F
-(ersion)-.15 E(2.8.)323.2 358.44 Q F3 3(1.2. Ov)323.2 388.44 R(er)-.12 E
-(view of Berk)-.12 E(eley DB)-.12 E F4 3.094(The C interf)323.2 404.64 R
-3.094(aces in Berk)-.1 F(ele)-.1 E 5.594(yD)-.15 G 5.595(Bp)-5.594 G
-(ermit)-5.595 E F6(dbm)5.595 E F4(-style)A 4.586
-(record management for databases, with signi\214cant)323.2 416.64 R -.15
-(ex)323.2 428.64 S 1.273(tensions to handle duplicate data items ele).15
-F -.05(ga)-.15 G(ntly).05 E 3.773(,t)-.65 G(o)-3.773 E 2.427
-(deal with concurrent access, and to pro)323.2 440.64 R 2.427
-(vide transac-)-.15 F .71
-(tional support so that multiple changes can be simulta-)323.2 452.64 R
-1.273(neously committed \(so that the)323.2 464.64 R 3.773(ya)-.15 G
-1.273(re made permanent\))-3.773 F 1.848
-(or rolled back \(so that the database is restored to its)323.2 476.64 R
-(state at the be)323.2 488.64 Q(ginning of the transaction\).)-.15 E
-1.034(C++ and Ja)323.2 504.84 R 1.534 -.25(va i)-.2 H(nterf).25 E 1.033
-(aces pro)-.1 F 1.033(vide a small set of classes)-.15 F 1.961
-(for operating on a database.)323.2 516.84 R 1.961
-(The main class in both)6.961 F .587(cases is called)323.2 528.84 R F6
-(Db)3.086 E F4 3.086(,a)C .586(nd pro)-3.086 F .586
-(vides methods that encapsu-)-.15 F 1.128(late the)323.2 540.84 R F6
-(dbm)3.628 E F4 1.129(-style interf)B 1.129(aces that the C interf)-.1 F
-1.129(aces pro-)-.1 F(vide.)323.2 552.84 Q 2.565(Tcl and Perl interf)
-323.2 569.04 R 2.564(aces allo)-.1 F 5.064(wd)-.25 G -2.15 -.25(ev e)
--5.064 H 2.564(lopers w).25 F 2.564(orking in)-.1 F 1.716
-(those languages to use Berk)323.2 581.04 R(ele)-.1 E 4.216(yD)-.15 G
-4.216(Bi)-4.216 G 4.217(nt)-4.216 G 1.717(heir applica-)-4.217 F 3.419
-(tions. Bindings)323.2 593.04 R .919
-(for both languages are included in the)3.419 F(distrib)323.2 605.04 Q
-(ution.)-.2 E(De)323.2 621.24 Q -.15(ve)-.25 G 1.069
-(lopers may compile their applications and link in).15 F(Berk)323.2
-633.24 Q(ele)-.1 E 2.5(yD)-.15 G 2.5(Bs)-2.5 G(tatically or dynamically)
--2.5 E(.)-.65 E F3 3(1.3. Ho)323.2 663.24 R 3(wB)-.12 G(erk)-3 E
-(eley DB is used)-.12 E F4 .655(The Berk)323.2 679.44 R(ele)-.1 E 3.155
-(yD)-.15 G 3.154(Bl)-3.155 G .654(ibrary supports concurrent access to)
--3.154 F 5.115(databases. It)323.2 691.44 R 2.616(can be link)5.115 F
-2.616(ed into standalone applica-)-.1 F 1.487
-(tions, into a collection of cooperating applications, or)323.2 703.44 R
-4.21(into serv)323.2 715.44 R 4.21
-(ers that handle requests and do database)-.15 F EP
-%%Page: 2 2
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 10/Times-Roman@0 SF(operations on behalf of clients.)79.2 84 Q .858
-(Compared to using a standalone database management)79.2 100.2 R .846
-(system, Berk)79.2 112.2 R(ele)-.1 E 3.346(yD)-.15 G 3.346(Bi)-3.346 G
-3.346(se)-3.346 G .846(asy to understand and simple)-3.346 F 3.826
-(to use.)79.2 124.2 R 3.826(The softw)8.826 F 3.826
-(are stores and retrie)-.1 F -.15(ve)-.25 G 6.325(sr).15 G(ecords,)
--6.325 E 2.77(which consist of k)79.2 136.2 R -.15(ey)-.1 G(/v).15 E
-2.77(alue pairs.)-.25 F -2.15 -.25(Ke y)7.77 H 5.27(sa).25 G 2.77
-(re used to)-5.27 F .698(locate items and can be an)79.2 148.2 R 3.198
-(yd)-.15 G .698(ata type or structure sup-)-3.198 F
-(ported by the programming language.)79.2 160.2 Q .813
-(The programmer can pro)79.2 176.4 R .813(vide the functions that Berk)
--.15 F(e-)-.1 E(le)79.2 188.4 Q 3.264(yD)-.15 G 3.264(Bu)-3.264 G .763
-(ses to operate on k)-3.264 F -.15(ey)-.1 G 3.263(s. F).15 F .763(or e)
--.15 F .763(xample, B+trees)-.15 F 1.72
-(can use a custom comparison function, and the Hash)79.2 200.4 R .519
-(access method can use a custom hash function.)79.2 212.4 R(Berk)5.518 E
-(e-)-.1 E(le)79.2 224.4 Q 5.222(yD)-.15 G 5.222(Bu)-5.222 G 2.722
-(ses def)-5.222 F 2.723(ault functions if none are supplied.)-.1 F .873
-(Otherwise, Berk)79.2 236.4 R(ele)-.1 E 3.373(yD)-.15 G 3.373(Bd)-3.373
-G .873(oes not e)-3.373 F .873(xamine or interpret)-.15 F .934(either k)
-79.2 248.4 R -.15(ey)-.1 G 3.434(so).15 G 3.434(rv)-3.434 G .934
-(alues in an)-3.684 F 3.434(yw)-.15 G(ay)-3.534 E 5.934(.V)-.65 G .934
-(alues may be arbi-)-7.044 F(trarily long.)79.2 260.4 Q .69
-(It is also important to understand what Berk)79.2 276.6 R(ele)-.1 E
-3.19(yD)-.15 G 3.19(Bi)-3.19 G(s)-3.19 E 4.365(not. It)79.2 288.6 R
-1.865(is not a database serv)4.365 F 1.866(er that handles netw)-.15 F
-(ork)-.1 E 2.797(requests. It)79.2 300.6 R .297
-(is not an SQL engine that e)2.797 F -.15(xe)-.15 G .296(cutes queries.)
-.15 F 1.547(It is not a relational or object-oriented database man-)79.2
-312.6 R(agement system.)79.2 324.6 Q 1.101(It is possible to b)79.2
-340.8 R 1.101(uild an)-.2 F 3.601(yo)-.15 G 3.601(ft)-3.601 G 1.101
-(hose on top of Berk)-3.601 F(ele)-.1 E(y)-.15 E 2.116(DB, b)79.2 352.8
-R 2.116(ut the package, as distrib)-.2 F 2.117(uted, is an embedded)-.2
-F 1.444(database engine.)79.2 364.8 R 1.444
-(It has been designed to be portable,)6.444 F(small, f)79.2 376.8 Q
-(ast, and reliable.)-.1 E/F1 12/Times-Bold@0 SF 3(1.4. A)79.2 406.8 R
-(pplications that use Berk)-.3 E(eley DB)-.12 E F0(Berk)79.2 423 Q(ele)
--.1 E 4.248(yD)-.15 G 4.248(Bi)-4.248 G 4.249(se)-4.248 G 1.749
-(mbedded in a v)-4.249 F 1.749(ariety of proprietary)-.25 F 3.84
-(and Open Source softw)79.2 435 R 3.84(are packages.)-.1 F 3.84
-(This section)8.84 F(highlights a fe)79.2 447 Q 2.5(wo)-.25 G 2.5(ft)
--2.5 G(he products that use it.)-2.5 E 1.467(Directory serv)79.2 463.2 R
-1.467(ers, which do data storage and retrie)-.15 F -.25(va)-.25 G(l).25
-E 2.823(using the Local Directory Access Protocol \(LD)79.2 475.2 R
-(AP\),)-.4 E(pro)79.2 487.2 Q .956
-(vide naming and directory lookup service on local-)-.15 F 2.837
-(area netw)79.2 499.2 R 5.337(orks. This)-.1 F 2.837
-(service is, essentially)5.337 F 5.336(,d)-.65 G(atabase)-5.336 E .039
-(query and update, b)79.2 511.2 R .039
-(ut uses a simple protocol rather than)-.2 F 2.202(SQL or ODBC.)79.2
-523.2 R(Berk)7.201 E(ele)-.1 E 4.701(yD)-.15 G 4.701(Bi)-4.701 G 4.701
-(st)-4.701 G 2.201(he embedded data)-4.701 F 1.288
-(manager in the majority of deplo)79.2 535.2 R 1.289(yed directory serv)
--.1 F(ers)-.15 E(today)79.2 547.2 Q 4.855(,i)-.65 G 2.355(ncluding LD)
--4.855 F 2.355(AP serv)-.4 F 2.355(ers from Netscape, Mes-)-.15 F
-(sageDirect \(formerly Isode\), and others.)79.2 559.2 Q(Berk)79.2 575.4
-Q(ele)-.1 E 4.385(yD)-.15 G 4.385(Bi)-4.385 G 4.385(sa)-4.385 G 1.886
-(lso embedded in a lar)-4.385 F 1.886(ge number of)-.18 F 5.302
-(mail serv)79.2 587.4 R 7.802(ers. Intermail,)-.15 F 5.302(from Softw)
-7.802 F 5.302(are.com, uses)-.1 F(Berk)79.2 599.4 Q(ele)-.1 E 4.613(yD)
--.15 G 4.613(Ba)-4.613 G 4.613(sam)-4.613 G 2.114
-(essage store and as the backing)-4.613 F 3.597
-(store for its directory serv)79.2 611.4 R(er)-.15 E 8.597(.T)-.55 G
-3.597(he sendmail serv)-8.597 F(er)-.15 E 1.175
-(\(including both the commercial Sendmail Pro of)79.2 623.4 R(fering)
--.25 E 3.283(from Sendmail, Inc. and the v)79.2 635.4 R 3.283
-(ersion distrib)-.15 F 3.282(uted by)-.2 F(sendmail.or)79.2 647.4 Q
-2.304(g\) uses Berk)-.18 F(ele)-.1 E 4.804(yD)-.15 G 4.804(Bt)-4.804 G
-4.804(os)-4.804 G 2.305(tore aliases and)-4.804 F 9.01
-(other information.)79.2 659.4 R(Similarly)14.01 E 11.51(,P)-.65 G 9.01
-(ost\214x \(formerly)-11.51 F 3.465(VMailer\) uses Berk)79.2 671.4 R
-(ele)-.1 E 5.965(yD)-.15 G 5.965(Bt)-5.965 G 5.965(os)-5.965 G 3.465
-(tore administrati)-5.965 F -.15(ve)-.25 G(information.)79.2 683.4 Q
-.134(In addition, Berk)79.2 699.6 R(ele)-.1 E 2.634(yD)-.15 G 2.633(Bi)
--2.634 G 2.633(se)-2.633 G .133(mbedded in a wide v)-2.633 F(ariety)-.25
-E 4.994(of other softw)79.2 711.6 R 4.994(are products.)-.1 F 4.994
-(Example applications)9.994 F .373
-(include managing access control lists, storing user k)323.2 84 R -.15
-(ey)-.1 G(s).15 E 2.75(in a public-k)323.2 96 R 3.05 -.15(ey i)-.1 H
-2.75(nfrastructure, recording machine-to-).15 F(netw)323.2 108 Q .519
-(ork-address mappings in address serv)-.1 F .518(ers, and stor)-.15 F(-)
--.2 E .411(ing con\214guration and de)323.2 120 R .412
-(vice information in video post-)-.25 F(production softw)323.2 132 Q
-(are.)-.1 E(Finally)323.2 148.2 Q 4.978(,B)-.65 G(erk)-4.978 E(ele)-.1 E
-4.978(yD)-.15 G 4.978(Bi)-4.978 G 4.978(sap)-4.978 G 2.478(art of man)
--4.978 F 4.977(yo)-.15 G 2.477(ther Open)-4.977 F .005(Source softw)
-323.2 160.2 R .005(are packages a)-.1 F -.25(va)-.2 G .006
-(ilable on the Internet.).25 F -.15(Fo)5.006 G(r).15 E -.15(ex)323.2
-172.2 S .604(ample, the softw).15 F .604
-(are is embedded in the Apache W)-.1 F(eb)-.8 E(serv)323.2 184.2 Q
-(er and the Gnome desktop.)-.15 E F1 3(2. Access)323.2 214.2 R(Methods)3
-E F0 .828(In database terminology)323.2 230.4 R 3.329(,a)-.65 G 3.329
-(na)-3.329 G .829(ccess method is the disk-)-3.329 F 1.964
-(based structure used to store data and the operations)323.2 242.4 R -.2
-(av)323.2 254.4 S 6.053(ailable on that structure.)-.05 F -.15(Fo)11.053
-G 8.554(re).15 G 6.054(xample, man)-8.704 F(y)-.15 E 3.853
-(database systems support a B+tree access method.)323.2 266.4 R 1.203
-(B+trees allo)323.2 278.4 R 3.703(we)-.25 G 1.203
-(quality-based lookups \(\214nd k)-3.703 F -.15(ey)-.1 G 3.704(se).15 G
-(qual)-3.704 E 4(to some constant\), range-based lookups \(\214nd k)
-323.2 290.4 R -.15(ey)-.1 G(s).15 E 1.188(between tw)323.2 302.4 R 3.688
-(oc)-.1 G 1.189(onstants\) and record insertion and dele-)-3.688 F
-(tion.)323.2 314.4 Q(Berk)323.2 330.6 Q(ele)-.1 E 4.729(yD)-.15 G 4.729
-(Bs)-4.729 G 2.228(upports three access methods: B+tree,)-4.729 F 1.553
-(Extended Linear Hashing \(Hash\), and Fix)323.2 342.6 R 1.553(ed- or V)
--.15 F(ari-)-1.11 E 3.639(able-length Records \(Recno\).)323.2 354.6 R
-3.638(All three operate on)8.638 F 1.956(records composed of a k)323.2
-366.6 R 2.256 -.15(ey a)-.1 H 1.956(nd a data v).15 F 4.456(alue. In)
--.25 F(the)4.456 E 1.301(B+tree and Hash access methods, k)323.2 378.6 R
--.15(ey)-.1 G 3.801(sc).15 G 1.301(an ha)-3.801 F 1.601 -.15(ve a)-.2 H
-(rbi-).15 E 3.595(trary structure.)323.2 390.6 R 3.596
-(In the Recno access method, each)8.595 F .266
-(record is assigned a record number)323.2 402.6 R 2.765(,w)-.4 G .265
-(hich serv)-2.765 F .265(es as the)-.15 F -.1(ke)323.2 414.6 S 4.106
--.65(y. I)-.05 H 2.806(na).65 G .306(ll the access methods, the v)-2.806
-F .306(alue can ha)-.25 F .606 -.15(ve a)-.2 H(rbi-).15 E 1.417
-(trary structure.)323.2 426.6 R 1.417
-(The programmer can supply compari-)6.417 F 2.129
-(son or hashing functions for k)323.2 438.6 R -.15(ey)-.1 G 2.129
-(s, and Berk).15 F(ele)-.1 E 4.629(yD)-.15 G(B)-4.629 E
-(stores and retrie)323.2 450.6 Q -.15(ve)-.25 G 2.5(sv).15 G
-(alues without interpreting them.)-2.75 E 1.069
-(All of the access methods use the host \214lesystem as a)323.2 466.8 R
-(backing store.)323.2 478.8 Q F1 3(2.1. Hash)323.2 508.8 R F0(Berk)323.2
-525 Q(ele)-.1 E 6.485(yD)-.15 G 6.485(Bi)-6.485 G 3.986
-(ncludes a Hash access method that)-6.485 F 9.863(implements e)323.2 537
-R 9.862(xtended linear hashing [Litw80].)-.15 F .017
-(Extended linear hashing adjusts the hash function as the)323.2 549 R
-.507(hash table gro)323.2 561 R .506(ws, attempting to k)-.25 F .506
-(eep all b)-.1 F(uck)-.2 E .506(ets under)-.1 F(-)-.2 E
-(full in the steady state.)323.2 573 Q 1.649
-(The Hash access method supports insertion and dele-)323.2 589.2 R .259
-(tion of records and lookup by e)323.2 601.2 R .259(xact match only)-.15
-F 5.258(.A)-.65 G(ppli-)-5.258 E .038(cations may iterate o)323.2 613.2
-R -.15(ve)-.15 G 2.538(ra).15 G .038(ll records stored in a table, b)
--2.538 F(ut)-.2 E(the order in which the)323.2 625.2 Q 2.5(ya)-.15 G
-(re returned is unde\214ned.)-2.5 E F1 3(2.2. B+tr)323.2 655.2 R(ee)
--.216 E F0(Berk)323.2 671.4 Q(ele)-.1 E 7.184(yD)-.15 G 7.184(Bi)-7.184
-G 4.683(ncludes a B+tree [Come79] access)-7.184 F 2.502(method. B+trees)
-323.2 683.4 R .002(store records of k)2.502 F -.15(ey)-.1 G(/v).15 E
-.003(alue pairs in leaf)-.25 F .52(pages, and pairs of \(k)323.2 695.4 R
--.15(ey)-.1 G 3.02(,c)-.5 G .52(hild page address\) at internal)-3.02 F
-5.384(nodes. K)323.2 707.4 R -.15(ey)-.25 G 5.384(si).15 G 5.384(nt)
--5.384 G 2.885(he tree are stored in sorted order)-5.384 F(,)-.4 E EP
-%%Page: 3 3
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 10/Times-Roman@0 SF .576
-(where the order is determined by the comparison func-)79.2 84 R .815
-(tion supplied when the database w)79.2 96 R .815(as created.)-.1 F -.15
-(Pa)5.815 G .815(ges at).15 F .389(the leaf le)79.2 108 R -.15(ve)-.25 G
-2.889(lo).15 G 2.889(ft)-2.889 G .389
-(he tree include pointers to their neigh-)-2.889 F 1.444
-(bors to simplify tra)79.2 120 R -.15(ve)-.2 G 3.944(rsal. B+trees).15 F
-1.445(support lookup by)3.944 F -.15(ex)79.2 132 S .068
-(act match \(equality\) or range \(greater than or equal to).15 F 2.891
-(ak)79.2 144 S -.15(ey)-2.991 G 2.891(\). Lik).15 F 2.891(eH)-.1 G .391
-(ash tables, B+trees support record inser)-2.891 F(-)-.2 E
-(tion, deletion, and iteration o)79.2 156 Q -.15(ve)-.15 G 2.5(ra).15 G
-(ll records in the tree.)-2.5 E .646
-(As records are inserted and pages in the B+tree \214ll up,)79.2 172.2 R
-(the)79.2 184.2 Q 2.722(ya)-.15 G .223(re split, with about half the k)
--2.722 F -.15(ey)-.1 G 2.723(sg).15 G .223(oing into a ne)-2.723 F(w)
--.25 E 1.603(peer page at the same le)79.2 196.2 R -.15(ve)-.25 G 4.103
-(li).15 G 4.103(nt)-4.103 G 1.603(he tree.)-4.103 F 1.603(Most B+tree)
-6.603 F .387(implementations lea)79.2 208.2 R .687 -.15(ve b)-.2 H .387
-(oth nodes half-full after a split.).15 F 2.763
-(This leads to poor performance in a common case,)79.2 220.2 R 1.522
-(where the caller inserts k)79.2 232.2 R -.15(ey)-.1 G 4.022(si).15 G
-4.022(no)-4.022 G(rder)-4.022 E 6.522(.T)-.55 G 4.023(oh)-7.322 G 1.523
-(andle this)-4.023 F 1.643(case, Berk)79.2 244.2 R(ele)-.1 E 4.143(yD)
--.15 G 4.143(Bk)-4.143 G 1.642(eeps track of the insertion order)-4.243
-F(,)-.4 E 2.023(and splits pages une)79.2 256.2 R -.15(ve)-.25 G 2.024
-(nly to k).15 F 2.024(eep pages fuller)-.1 F 7.024(.T)-.55 G(his)-7.024
-E 2.3(reduces tree size, yielding better search performance)79.2 268.2 R
-(and smaller databases.)79.2 280.2 Q 3.177
-(On deletion, empty pages are coalesced by re)79.2 296.4 R -.15(ve)-.25
-G(rse).15 E 2.03(splits into single pages.)79.2 308.4 R 2.03
-(The access method does no)7.03 F .347
-(other page balancing on insertion or deletion.)79.2 320.4 R -2.15 -.25
-(Ke y)5.348 H 2.848(sa).25 G(re)-2.848 E 1.927(not mo)79.2 332.4 R -.15
-(ve)-.15 G 4.427(da).15 G 1.927(mong pages at e)-4.427 F -.15(ve)-.25 G
-1.926(ry update to k).15 F 1.926(eep the)-.1 F 2.206
-(tree well-balanced.)79.2 344.4 R 2.207(While this could impro)7.206 F
-2.507 -.15(ve s)-.15 H(earch).15 E 2.341
-(times in some cases, the additional code comple)79.2 356.4 R(xity)-.15
-E(leads to slo)79.2 368.4 Q(wer updates and is prone to deadlocks.)-.25
-E -.15(Fo)79.2 384.6 S 2.948(rs).15 G(implicity)-2.948 E 2.948(,B)-.65 G
-(erk)-2.948 E(ele)-.1 E 2.949(yD)-.15 G 2.949(BB)-2.949 G .449
-(+trees do no pre\214x com-)-2.949 F(pression of k)79.2 396.6 Q -.15(ey)
--.1 G 2.5(sa).15 G 2.5(ti)-2.5 G(nternal or leaf nodes.)-2.5 E/F1 12
-/Times-Bold@0 SF 3(2.3. Recno)79.2 426.6 R F0(Berk)79.2 442.8 Q(ele)-.1
-E 2.736(yD)-.15 G 2.736(Bi)-2.736 G .236(ncludes a \214x)-2.736 F .236
-(ed- or v)-.15 F .235(ariable-length record)-.25 F 5.075
-(access method, called)79.2 454.8 R/F2 10/Times-Italic@0 SF(Recno)7.575
-E F0 10.075(.T)C 5.075(he Recno access)-10.075 F .896
-(method assigns logical record numbers to each record,)79.2 466.8 R .978
-(and can search for and update records by record num-)79.2 478.8 R(ber)
-79.2 490.8 Q 5.037(.R)-.55 G .037(ecno is able, for e)-5.037 F .037
-(xample, to load a te)-.15 F .036(xt \214le into a)-.15 F 1.514
-(database, treating each line as a record.)79.2 502.8 R 1.514
-(This permits)6.514 F -.1(fa)79.2 514.8 S 1.313
-(st searches by line number for applications lik).1 F 3.812(et)-.1 G
--.15(ex)-3.812 G(t).15 E(editors [Ston82].)79.2 526.8 Q 2.59
-(Recno is actually b)79.2 543 R 2.59(uilt on top of the B+tree access)
--.2 F 3.192(method and pro)79.2 555 R 3.191(vides a simple interf)-.15 F
-3.191(ace for storing)-.1 F 3.14(sequentially-ordered data v)79.2 567 R
-5.64(alues. The)-.25 F 3.14(Recno access)5.64 F 2.266
-(method generates k)79.2 579 R -.15(ey)-.1 G 4.766(si).15 G(nternally)
--4.766 E 7.266(.T)-.65 G 2.266(he programmer')-7.266 F(s)-.55 E(vie)79.2
-591 Q 4.102(wo)-.25 G 4.102(ft)-4.102 G 1.602(he v)-4.102 F 1.602
-(alues is that the)-.25 F 4.102(ya)-.15 G 1.603(re numbered sequen-)
--4.102 F .254(tially from one.)79.2 603 R(De)5.254 E -.15(ve)-.25 G .254
-(lopers can choose to ha).15 F .553 -.15(ve r)-.2 H(ecords).15 E 9
-(automatically renumbered when lo)79.2 615 R(wer)-.25 E(-numbered)-.2 E
-.041(records are added or deleted.)79.2 627 R .041(In this case, ne)
-5.041 F 2.541(wk)-.25 G -.15(ey)-2.641 G 2.541(sc).15 G(an)-2.541 E
-(be inserted between e)79.2 639 Q(xisting k)-.15 E -.15(ey)-.1 G(s.).15
-E F1 3(3. F)79.2 669 R(eatur)-.3 E(es)-.216 E F0 1.827
-(This section describes important features of Berk)79.2 685.2 R(ele)-.1
-E(y)-.15 E 3.456(DB. In)79.2 697.2 R .956(general, de)3.456 F -.15(ve)
--.25 G .956(lopers can choose which features).15 F .488
-(are useful to them, and use only those that are required)79.2 709.2 R
-(by their application.)323.2 84 Q -.15(Fo)323.2 100.2 S 3.529(re).15 G
-1.029(xample, when an application opens a database, it)-3.679 F .101
-(can declare the de)323.2 112.2 R .101(gree of concurrenc)-.15 F 2.601
-(ya)-.15 G .102(nd reco)-2.601 F -.15(ve)-.15 G .102(ry that).15 F .049
-(it requires.)323.2 124.2 R .048
-(Simple stand-alone applications, and in par)5.049 F(-)-.2 E .491
-(ticular ports of applications that used)323.2 136.2 R/F3 10/Courier@0
-SF(dbm)2.991 E F0 .491(or one of its)2.991 F -.25(va)323.2 148.2 S 1.093
-(riants, generally do not require concurrent access or).25 F .975
-(crash reco)323.2 160.2 R -.15(ve)-.15 G(ry).15 E 5.975(.O)-.65 G .975
-(ther applications, such as enterprise-)-5.975 F 3.08
-(class database management systems that store sales)323.2 172.2 R 2.643
-(transactions or other critical data, need full transac-)323.2 184.2 R
-3.93(tional service.)323.2 196.2 R 3.93(Single-user operation is f)8.93
-F 3.93(aster than)-.1 F 1.175(multi-user operation, since no o)323.2
-208.2 R -.15(ve)-.15 G 1.176(rhead is incurred by).15 F 3.156
-(locking. Running)323.2 220.2 R .656(with the reco)3.156 F -.15(ve)-.15
-G .655(ry system disabled is).15 F -.1(fa)323.2 232.2 S 1.732
-(ster than running with it enabled, since log records).1 F 2.703
-(need not be written when changes are made to the)323.2 244.2 R
-(database.)323.2 256.2 Q .851
-(In addition, some core subsystems, including the lock-)323.2 272.4 R
-.345(ing system and the logging f)323.2 284.4 R(acility)-.1 E 2.844(,c)
--.65 G .344(an be used outside)-2.844 F 1.772(the conte)323.2 296.4 R
-1.772(xt of the access methods as well.)-.15 F(Although)6.773 E(fe)323.2
-308.4 Q 4.284(wu)-.25 G 1.784(sers ha)-4.284 F 2.084 -.15(ve c)-.2 H
-1.784(hosen to do so, it is possible to use).15 F .939
-(only the lock manager in Berk)323.2 320.4 R(ele)-.1 E 3.439(yD)-.15 G
-3.439(Bt)-3.439 G 3.439(oc)-3.439 G .939(ontrol con-)-3.439 F(currenc)
-323.2 332.4 Q 4.743(yi)-.15 G 4.743(na)-4.743 G 4.743(na)-4.743 G 2.242
-(pplication, without using an)-4.743 F 4.742(yo)-.15 G 4.742(ft)-4.742 G
-(he)-4.742 E .158(standard database services.)323.2 344.4 R(Alternati)
-5.158 E -.15(ve)-.25 G(ly).15 E 2.658(,t)-.65 G .159(he caller can)
--2.658 F(inte)323.2 356.4 Q .07
-(grate locking of non-database resources with Berk)-.15 F(e-)-.1 E(le)
-323.2 368.4 Q 5.201(yD)-.15 G(B')-5.201 E 5.201(st)-.55 G 2.702
-(ransactional tw)-5.201 F 2.702(o-phase locking system, to)-.1 F 2.892
-(impose transaction semantics on objects outside the)323.2 380.4 R
-(database.)323.2 392.4 Q F1 3(3.1. Pr)323.2 422.4 R
-(ogrammatic interfaces)-.216 E F0(Berk)323.2 438.6 Q(ele)-.1 E 4.008(yD)
--.15 G 4.008(Bd)-4.008 G 1.509(e\214nes a simple API for database man-)
--4.008 F 3.452(agement. The)323.2 450.6 R .952
-(package does not include industry-stan-)3.452 F 1.898
-(dard programmatic interf)323.2 462.6 R 1.898
-(aces such as Open Database)-.1 F(Connecti)323.2 474.6 Q .852
-(vity \(ODBC\), Object Linking and Embedding)-.25 F .817
-(for Databases \(OleDB\), or Structured Query Language)323.2 486.6 R
-4.027(\(SQL\). These)323.2 498.6 R(interf)4.027 E 1.527
-(aces, while useful, were designed)-.1 F 2.477
-(to promote interoperability of database systems, and)323.2 510.6 R
-(not simplicity or performance.)323.2 522.6 Q 3.192
-(In response to customer demand, Berk)323.2 538.8 R(ele)-.1 E 5.691(yD)
--.15 G 5.691(B2)-5.691 G(.5)-5.691 E .538
-(introduced support for the XA standard [Open94].)323.2 550.8 R(XA)5.539
-E .52(permits Berk)323.2 562.8 R(ele)-.1 E 3.02(yD)-.15 G 3.02(Bt)-3.02
-G 3.02(op)-3.02 G .52(articipate in distrib)-3.02 F .52(uted trans-)-.2
-F 3.373(actions under a transaction processing monitor lik)323.2 574.8 R
-(e)-.1 E -.45(Tu)323.2 586.8 S -.15(xe).45 G 1.31(do from BEA Systems.)
-.15 F(Lik)6.31 E 3.81(eX)-.1 G 1.31(A, other standard)-3.81 F(interf)
-323.2 598.8 Q .99(aces can be b)-.1 F .99
-(uilt on top of the core system.)-.2 F(The)5.99 E .846
-(standards do not belong inside Berk)323.2 610.8 R(ele)-.1 E 3.346(yD)
--.15 G .846(B, since not)-3.346 F(all applications need them.)323.2
-622.8 Q F1 3(3.2. W)323.2 652.8 R(orking with r)-.9 E(ecords)-.216 E F0
-3.134(Ad)323.2 669 S .634
-(atabase user may need to search for particular k)-3.134 F -.15(ey)-.1 G
-(s).15 E .908(in a database, or may simply w)323.2 681 R .908
-(ant to bro)-.1 F .907(wse a)-.25 F -.25(va)-.2 G(ilable).25 E 4.101
-(records. Berk)323.2 693 R(ele)-.1 E 4.101(yD)-.15 G 4.101(Bs)-4.101 G
-1.601(upports both k)-4.101 F -.15(ey)-.1 G 1.602(ed access, to).15 F
-.173(\214nd one or more records with a gi)323.2 705 R -.15(ve)-.25 G
-2.673(nk).15 G -.15(ey)-2.773 G 2.673(,o)-.5 G 2.673(rs)-2.673 G
-(equential)-2.673 E .53(access, to retrie)323.2 717 R .83 -.15(ve a)-.25
-H .53(ll the records in the database one at).15 F EP
-%%Page: 4 4
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 10/Times-Roman@0 SF 6.34(at)79.2 84 S 6.34(ime. The)-6.34 F 3.84
-(order of the records returned during)6.34 F .208
-(sequential scans depends on the access method.)79.2 96 R(B+tree)5.209 E
-1.495(and Recno databases return records in sort order)79.2 108 R 3.995
-(,a)-.4 G(nd)-3.995 E .023
-(Hash databases return them in apparently random order)79.2 120 R(.)-.55
-E(Similarly)79.2 136.2 Q 4.959(,B)-.65 G(erk)-4.959 E(ele)-.1 E 4.959
-(yD)-.15 G 4.958(Bd)-4.959 G 2.458(e\214nes simple interf)-4.958 F 2.458
-(aces for)-.1 F
-(inserting, updating, and deleting records in a database.)79.2 148.2 Q
-/F1 12/Times-Bold@0 SF 3(3.3. Long)79.2 178.2 R -.12(ke)3 G(ys and v).12
-E(alues)-.12 E F0(Berk)79.2 194.4 Q(ele)-.1 E 3.553(yD)-.15 G 3.553(Bm)
--3.553 G 1.053(anages k)-3.553 F -.15(ey)-.1 G 3.553(sa).15 G 1.053
-(nd v)-3.553 F 1.053(alues as lar)-.25 F 1.054(ge as 2)-.18 F/F2 8
-/Times-Roman@0 SF(32)-5 I F0 3.192(bytes. Since)79.2 206.4 R .692
-(the time required to cop)3.192 F 3.192(yar)-.1 G .692(ecord is pro-)
--3.192 F 1.895(portional to its size, Berk)79.2 218.4 R(ele)-.1 E 4.396
-(yD)-.15 G 4.396(Bi)-4.396 G 1.896(ncludes interf)-4.396 F(aces)-.1 E
-4.507(that operate on partial records.)79.2 230.4 R 4.507
-(If an application)9.507 F 1.273(requires only part of a lar)79.2 242.4
-R 1.274(ge record, it requests partial)-.18 F .026(record retrie)79.2
-254.4 R -.25(va)-.25 G .026(l, and recei).25 F -.15(ve)-.25 G 2.526(sj)
-.15 G .025(ust the bytes that it needs.)-2.526 F(The smaller cop)79.2
-266.4 Q 2.5(ys)-.1 G -2.25 -.2(av e)-2.5 H 2.5(sb).2 G
-(oth time and memory)-2.5 E(.)-.65 E(Berk)79.2 282.6 Q(ele)-.1 E 3.206
-(yD)-.15 G 3.206(Ba)-3.206 G(llo)-3.206 E .706
-(ws the programmer to de\214ne the data)-.25 F 2.72(types of k)79.2
-294.6 R -.15(ey)-.1 G 5.22(sa).15 G 2.72(nd v)-5.22 F 5.22(alues. De)
--.25 F -.15(ve)-.25 G 2.72(lopers use an).15 F 5.22(yt)-.15 G(ype)-5.22
-E -.15(ex)79.2 306.6 S(pressible in the programming language.).15 E F1 3
-(3.4. Lar)79.2 336.6 R(ge databases)-.12 E F0 3.255(As)79.2 352.8 S .755
-(ingle database managed by Berk)-3.255 F(ele)-.1 E 3.256(yD)-.15 G 3.256
-(Bc)-3.256 G .756(an be up)-3.256 F 1.716(to 2)79.2 364.8 R F2(48)-5 I
-F0 1.716(bytes, or 256 petabytes, in size.)4.216 5 N(Berk)6.715 E(ele)
--.1 E 4.215(yD)-.15 G(B)-4.215 E 2.144
-(uses the host \214lesystem as the backing store for the)79.2 376.8 R
-2.668(database, so lar)79.2 388.8 R 2.667
-(ge databases require big \214le support)-.18 F 3.113
-(from the operating system.)79.2 400.8 R(Sleep)8.113 E 3.114(ycat Softw)
--.1 F 3.114(are has)-.1 F 5.712(customers using Berk)79.2 412.8 R(ele)
--.1 E 8.212(yD)-.15 G 8.212(Bt)-8.212 G 8.211(om)-8.212 G 5.711
-(anage single)-8.211 F(databases in e)79.2 424.8 Q(xcess of 100 gig)-.15
-E(abytes.)-.05 E F1 3(3.5. Main)79.2 454.8 R(memory databases)3 E F0
-1.171(Applications that do not require persistent storage can)79.2 471 R
-.119(create databases that e)79.2 483 R .119(xist only in main memory)
--.15 F 5.118(.T)-.65 G(hese)-5.118 E .542(databases bypass the o)79.2
-495 R -.15(ve)-.15 G .543(rhead imposed by the I/O sys-).15 F
-(tem altogether)79.2 507 Q(.)-.55 E 2.144
-(Some applications do need to use disk as a backing)79.2 523.2 R 2.248
-(store, b)79.2 535.2 R 2.249(ut run on machines with v)-.2 F 2.249
-(ery lar)-.15 F 2.249(ge memory)-.18 F(.)-.65 E(Berk)79.2 547.2 Q(ele)
--.1 E 2.799(yD)-.15 G 2.799(Bi)-2.799 G 2.799(sa)-2.799 G .299
-(ble to manage v)-2.799 F .299(ery lar)-.15 F .299(ge shared mem-)-.18 F
-.128(ory re)79.2 559.2 R .129
-(gions for cached data pages, log records, and lock)-.15 F 3.938
-(management. F)79.2 571.2 R 1.437(or e)-.15 F 1.437
-(xample, the cache re)-.15 F 1.437(gion used for)-.15 F .033
-(data pages may be gig)79.2 583.2 R .034
-(abytes in size, reducing the lik)-.05 F(eli-)-.1 E .639(hood that an)
-79.2 595.2 R 3.139(yr)-.15 G .639
-(ead operation will need to visit the disk)-3.139 F 1.201
-(in the steady state.)79.2 607.2 R 1.201
-(The programmer declares the size)6.201 F(of the cache re)79.2 619.2 Q
-(gion at startup.)-.15 E(Finally)79.2 635.4 Q 7.048(,m)-.65 G(an)-7.048
-E 7.048(yo)-.15 G 4.548(perating systems pro)-7.048 F 4.548
-(vide memory-)-.15 F 2.532(mapped \214le services that are much f)79.2
-647.4 R 2.533(aster than their)-.1 F 2.602
-(general-purpose \214le system interf)79.2 659.4 R 5.102(aces. Berk)-.1
-F(ele)-.1 E 5.102(yD)-.15 G(B)-5.102 E 5.118
-(can memory-map its database \214les for read-only)79.2 671.4 R 3.917
-(database use.)79.2 683.4 R 3.917(The application operates on records)
-8.917 F 2.069(stored directly on the pages, with no cache manage-)79.2
-695.4 R 1.557(ment o)79.2 707.4 R -.15(ve)-.15 G 4.057(rhead. Because)
-.15 F 1.556(the application gets pointers)4.057 F 1.265
-(directly into the Berk)323.2 84 R(ele)-.1 E 3.765(yD)-.15 G 3.765(Bp)
--3.765 G 1.265(ages, writes cannot be)-3.765 F 3.775
-(permitted. Otherwise,)323.2 96 R 1.275(changes could bypass the lock-)
-3.775 F .23(ing and logging systems, and softw)323.2 108 R .23
-(are errors could cor)-.1 F(-)-.2 E 4.007(rupt the database.)323.2 120 R
-4.006(Read-only applications can use)9.007 F(Berk)323.2 132 Q(ele)-.1 E
-2.893(yD)-.15 G(B')-2.893 E 2.893(sm)-.55 G .393
-(emory-mapped \214le service to impro)-2.893 F -.15(ve)-.15 G
-(performance on most architectures.)323.2 144 Q F1 3
-(3.6. Con\214gurable)323.2 174 R(page size)3 E F0 .111
-(Programmers declare the size of the pages used by their)323.2 190.2 R
-.403(access methods when the)323.2 202.2 R 2.903(yc)-.15 G .403
-(reate a database.)-2.903 F(Although)5.403 E(Berk)323.2 214.2 Q(ele)-.1
-E 4.046(yD)-.15 G 4.046(Bp)-4.046 G(ro)-4.046 E 1.546
-(vides reasonable def)-.15 F 1.546(aults, de)-.1 F -.15(ve)-.25 G
-(lopers).15 E 3.64(may o)323.2 226.2 R -.15(ve)-.15 G 3.64
-(rride them to control system performance.).15 F .793
-(Small pages reduce the number of records that \214t on a)323.2 238.2 R
-.353(single page.)323.2 250.2 R(Fe)5.353 E .353
-(wer records on a page means that fe)-.25 F(wer)-.25 E .724
-(records are lock)323.2 262.2 R .724(ed when the page is lock)-.1 F .723
-(ed, impro)-.1 F(ving)-.15 E(concurrenc)323.2 274.2 Q 5.262 -.65(y. T)
--.15 H 1.462(he per).65 F 1.462(-page o)-.2 F -.15(ve)-.15 G 1.462
-(rhead is proportionally).15 F 2.29
-(higher with smaller pages, of course, b)323.2 286.2 R 2.29(ut de)-.2 F
--.15(ve)-.25 G(lopers).15 E(can trade of)323.2 298.2 Q 2.5(fs)-.25 G
-(pace for time as an application requires.)-2.5 E F1 3(3.7. Small)323.2
-328.2 R -.3(fo)3 G(otprint).3 E F0(Berk)323.2 344.4 Q(ele)-.1 E 3.973
-(yD)-.15 G 3.973(Bi)-3.973 G 3.974(sac)-3.973 G 1.474(ompact system.)
--3.974 F 1.474(The full package,)6.474 F .832
-(including all access methods, reco)323.2 356.4 R -.15(ve)-.15 G
-(rability).15 E 3.331(,a)-.65 G .831(nd trans-)-3.331 F 1.235
-(action support is roughly 175K of te)323.2 368.4 R 1.236
-(xt space on com-)-.15 F(mon architectures.)323.2 380.4 Q F1 3
-(3.8. Cursors)323.2 410.4 R F0 1.57(In database terminology)323.2 426.6
-R 4.07(,ac)-.65 G 1.57(ursor is a pointer into an)-4.07 F 1.806
-(access method that can be called iterati)323.2 438.6 R -.15(ve)-.25 G
-1.807(ly to return).15 F 3.68(records in sequence.)323.2 450.6 R(Berk)
-8.68 E(ele)-.1 E 6.18(yD)-.15 G 6.18(Bi)-6.18 G 3.68(ncludes cursor)
--6.18 F(interf)323.2 462.6 Q 2.814(aces for all access methods.)-.1 F
-2.815(This permits, for)7.814 F -.15(ex)323.2 474.6 S .34
-(ample, users to tra).15 F -.15(ve)-.2 G .34(rse a B+tree and vie).15 F
-2.84(wr)-.25 G .34(ecords in)-2.84 F(order)323.2 486.6 Q 6.233(.P)-.55 G
-1.234(ointers to records in cursors are persistent, so)-6.233 F 1.779
-(that once fetched, a record may be updated in place.)323.2 498.6 R
-(Finally)323.2 510.6 Q 4.438(,c)-.65 G 1.939
-(ursors support access to chains of duplicate)-4.438 F
-(data items in the v)323.2 522.6 Q(arious access methods.)-.25 E F1 3
-(3.9. J)323.2 552.6 R(oins)-.18 E F0 2.703(In database terminology)323.2
-568.8 R 5.203(,aj)-.65 G 2.702(oin is an operation that)-5.203 F .616
-(spans multiple separate tables \(or in the case of Berk)323.2 580.8 R
-(e-)-.1 E(le)323.2 592.8 Q 4.518(yD)-.15 G 2.018
-(B, multiple separate DB \214les\).)-4.518 F -.15(Fo)7.017 G 4.517(re)
-.15 G 2.017(xample, a)-4.667 F(compan)323.2 604.8 Q 3.372(ym)-.15 G .873
-(ay store information about its customers in)-3.372 F 1.545
-(one table and information about sales in another)323.2 616.8 R 6.545
-(.A)-.55 G(n)-6.545 E 1.498(application will lik)323.2 628.8 R 1.499
-(ely w)-.1 F 1.499(ant to look up sales informa-)-.1 F .933
-(tion by customer name; this requires matching records)323.2 640.8 R
-2.28(in the tw)323.2 652.8 R 4.78(ot)-.1 G 2.28
-(ables that share a common customer ID)-4.78 F 2.515(\214eld. This)323.2
-664.8 R .015(combining of records from multiple tables is)2.515 F
-(called a join.)323.2 676.8 Q(Berk)323.2 693 Q(ele)-.1 E 5.561(yD)-.15 G
-5.561(Bi)-5.561 G 3.061(ncludes interf)-5.561 F 3.062
-(aces for joining tw)-.1 F 5.562(oo)-.1 G(r)-5.562 E(more tables.)323.2
-705 Q EP
-%%Page: 5 5
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 12/Times-Bold@0 SF 3(3.10. T)79.2 84 R(ransactions)-.888 E/F1 10
-/Times-Roman@0 SF -.35(Tr)79.2 100.2 S(ansactions ha).35 E .3 -.15(ve f)
--.2 H(our properties [Gray93]:).15 E/F2 8/Times-Roman@0 SF<83>84.2 116.4
-Q F1(The)17.2 E 5.489(ya)-.15 G 2.989(re atomic.)-5.489 F 2.989
-(That is, all of the changes)7.989 F 1.475
-(made in a single transaction must be applied at)104.2 128.4 R 1.31
-(the same instant or not at all.)104.2 140.4 R 1.31(This permits, for)
-6.31 F -.15(ex)104.2 152.4 S 3.565(ample, the transfer of mone).15 F
-6.065(yb)-.15 G 3.565(etween tw)-6.065 F(o)-.1 E 3.68
-(accounts to be accomplished, by making the)104.2 164.4 R 1.27
-(reduction of the balance in one account and the)104.2 176.4 R
-(increase in the other into a single, atomic action.)104.2 188.4 Q F2
-<83>84.2 204.6 Q F1(The)17.2 E 3.125(ym)-.15 G .625(ust be consistent.)
--3.125 F .625(That is, changes to the)5.625 F 3.628(database by an)104.2
-216.6 R 6.128(yt)-.15 G 3.628(ransaction cannot lea)-6.128 F 3.929 -.15
-(ve t)-.2 H(he).15 E(database in an ille)104.2 228.6 Q -.05(ga)-.15 G
-2.5(lo).05 G 2.5(rc)-2.5 G(orrupt state.)-2.5 E F2<83>84.2 244.8 Q F1
-(The)17.2 E 3.006(ym)-.15 G .506(ust be isolatable.)-3.006 F(Re)5.506 E
--.05(ga)-.15 G .505(rdless of the num-).05 F .8(ber of users w)104.2
-256.8 R .8(orking in the database at the same)-.1 F 1.88(time, e)104.2
-268.8 R -.15(ve)-.25 G 1.88(ry user must ha).15 F 2.18 -.15(ve t)-.2 H
-1.88(he illusion that no).15 F(other acti)104.2 280.8 Q
-(vity is going on.)-.25 E F2<83>84.2 297 Q F1(The)17.2 E 5.54(ym)-.15 G
-3.04(ust be durable.)-5.54 F(Ev)8.04 E 3.04(en if the disk that)-.15 F
-.877(stores the database is lost, it must be possible to)104.2 309 R
-(reco)104.2 321 Q -.15(ve)-.15 G 2.668(rt).15 G .168
-(he database to its last transaction-consis-)-2.668 F(tent state.)104.2
-333 Q 2.49(This combination of properties \212 atomicity)79.2 349.2 R
-4.99(,c)-.65 G(onsis-)-4.99 E(tenc)79.2 361.2 Q 4.542 -.65(y, i)-.15 H
-3.243(solation, and durability \212 is referred to as).65 F -.4(AC)79.2
-373.2 S 3.459(IDity in the literature.).4 F(Berk)8.459 E(ele)-.1 E 5.958
-(yD)-.15 G 3.458(B, lik)-5.958 F 5.958(em)-.1 G(ost)-5.958 E .993
-(database systems, pro)79.2 385.2 R .993(vides A)-.15 F .994
-(CIDity using a collection)-.4 F(of core services.)79.2 397.2 Q .257
-(Programmers can choose to use Berk)79.2 413.4 R(ele)-.1 E 2.757(yD)-.15
-G(B')-2.757 E 2.757(st)-.55 G(ransac-)-2.757 E
-(tion services for applications that need them.)79.2 425.4 Q F0 3
-(3.10.1. Write-ahead)79.2 455.4 R(logging)3 E F1 .479
-(Programmers can enable the logging system when the)79.2 471.6 R(y)-.15
-E .918(start up Berk)79.2 483.6 R(ele)-.1 E 3.418(yD)-.15 G 3.418
-(B. During)-3.418 F 3.417(at)3.417 G .917(ransaction, the appli-)-3.417
-F .493(cation mak)79.2 495.6 R .493
-(es a series of changes to the database.)-.1 F(Each)5.494 E .552
-(change is captured in a log entry)79.2 507.6 R 3.052(,w)-.65 G .552
-(hich holds the state)-3.052 F .207
-(of the database record both before and after the change.)79.2 519.6 R
-2.208(The log record is guaranteed to be \215ushed to stable)79.2 531.6
-R .871(storage before an)79.2 543.6 R 3.371(yo)-.15 G 3.371(ft)-3.371 G
-.871(he changed data pages are writ-)-3.371 F 3.989(ten. This)79.2 555.6
-R(beha)3.989 E 1.489(vior \212 writing the log before the data)-.2 F
-(pages \212 is called)79.2 567.6 Q/F3 10/Times-Italic@0 SF
-(write-ahead lo)2.5 E -.1(gg)-.1 G(ing).1 E F1(.)A .835(At an)79.2 583.8
-R 3.335(yt)-.15 G .835(ime during the transaction, the application can)
--3.335 F F3(commit)79.2 595.8 Q F1 4.202(,m)C 1.702
-(aking the changes permanent, or)-4.202 F F3 -.45(ro)4.201 G 1.701
-(ll bac).45 F(k)-.2 E F1(,)A .852
-(cancelling all changes and restoring the database to its)79.2 607.8 R
-1.57(pre-transaction state.)79.2 619.8 R 1.57
-(If the application rolls back the)6.57 F 1.003
-(transaction, then the log holds the state of all changed)79.2 631.8 R
-.5(pages prior to the transaction, and Berk)79.2 643.8 R(ele)-.1 E 3(yD)
--.15 G 3(Bs)-3 G(imply)-3 E .226(restores that state.)79.2 655.8 R .226
-(If the application commits the trans-)5.226 F .538(action, Berk)79.2
-667.8 R(ele)-.1 E 3.038(yD)-.15 G 3.038(Bw)-3.038 G .538
-(rites the log records to disk.)-3.038 F(In-)5.537 E 2.312
-(memory copies of the data pages already re\215ect the)79.2 679.8 R
-1.399(changes, and will be \215ushed as necessary during nor)79.2 691.8
-R(-)-.2 E 2.35(mal processing.)79.2 703.8 R 2.35
-(Since log writes are sequential, b)7.35 F(ut)-.2 E 8.732
-(data page writes are random, this impro)79.2 715.8 R -.15(ve)-.15 G(s)
-.15 E(performance.)323.2 84 Q F0 3(3.10.2. Crashes)323.2 114 R(and r)3 E
-(eco)-.216 E -.12(ve)-.12 G(ry).12 E F1(Berk)323.2 130.2 Q(ele)-.1 E
-3.592(yD)-.15 G(B')-3.592 E 3.592(sw)-.55 G 1.093
-(rite-ahead log is used by the transac-)-3.592 F .415
-(tion system to commit or roll back transactions.)323.2 142.2 R .414
-(It also)5.414 F(gi)323.2 154.2 Q -.15(ve)-.25 G 3.23(st).15 G .73
-(he reco)-3.23 F -.15(ve)-.15 G .73
-(ry system the information that it needs).15 F .824(to protect ag)323.2
-166.2 R .824(ainst data loss or corruption from crashes.)-.05 F(Berk)
-323.2 178.2 Q(ele)-.1 E 2.703(yD)-.15 G 2.703(Bi)-2.703 G 2.704(sa)
--2.703 G .204(ble to survi)-2.704 F .504 -.15(ve a)-.25 H .204
-(pplication crashes, sys-).15 F .408(tem crashes, and e)323.2 190.2 R
--.15(ve)-.25 G 2.908(nc).15 G .407(atastrophic f)-2.908 F .407
-(ailures lik)-.1 F 2.907(et)-.1 G .407(he loss)-2.907 F
-(of a hard disk, without losing an)323.2 202.2 Q 2.5(yd)-.15 G(ata.)-2.5
-E(Survi)323.2 218.4 Q .538(ving crashes requires data stored in se)-.25
-F -.15(ve)-.25 G .539(ral dif).15 F(fer)-.25 E(-)-.2 E 2.52(ent places.)
-323.2 230.4 R 2.52(During normal processing, Berk)7.52 F(ele)-.1 E 5.02
-(yD)-.15 G(B)-5.02 E .766(has copies of acti)323.2 242.4 R 1.066 -.15
-(ve l)-.25 H .766(og records and recently-used data).15 F 1.539
-(pages in memory)323.2 254.4 R 6.539(.L)-.65 G 1.539
-(og records are \215ushed to the log)-6.539 F .694
-(disk when transactions commit.)323.2 266.4 R .695
-(Data pages trickle out)5.694 F .008(to the data disk as pages mo)323.2
-278.4 R .308 -.15(ve t)-.15 H .008(hrough the b).15 F(uf)-.2 E .008
-(fer cache.)-.25 F(Periodically)323.2 290.4 Q 2.691(,t)-.65 G .191
-(he system administrator backs up the data)-2.691 F .278
-(disk, creating a safe cop)323.2 302.4 R 2.778(yo)-.1 G 2.778(ft)-2.778
-G .278(he database at a particular)-2.778 F 2.609(instant. When)323.2
-314.4 R .109(the database is back)2.609 F .109(ed up, the log can be)-.1
-F 3.838(truncated. F)323.2 326.4 R 1.337(or maximum rob)-.15 F 1.337
-(ustness, the log disk and)-.2 F(data disk should be separate de)323.2
-338.4 Q(vices.)-.25 E(Dif)323.2 354.6 Q 1.29(ferent system f)-.25 F 1.29
-(ailures can destro)-.1 F 3.79(ym)-.1 G(emory)-3.79 E 3.79(,t)-.65 G
-1.29(he log)-3.79 F 1.106(disk, or the data disk.)323.2 366.6 R(Berk)
-6.106 E(ele)-.1 E 3.606(yD)-.15 G 3.606(Bi)-3.606 G 3.606(sa)-3.606 G
-1.106(ble to survi)-3.606 F -.15(ve)-.25 G .679(the loss of an)323.2
-378.6 R 3.179(yo)-.15 G .679(ne of these repositories without losing)
--3.179 F(an)323.2 390.6 Q 2.5(yc)-.15 G(ommitted transactions.)-2.5 E
-1.372(If the computer')323.2 406.8 R 3.871(sm)-.55 G 1.371
-(emory is lost, through an applica-)-3.871 F 1.619
-(tion or operating system crash, then the log holds all)323.2 418.8 R
-1.789(committed transactions.)323.2 430.8 R 1.788(On restart, the reco)
-6.789 F -.15(ve)-.15 G 1.788(ry sys-).15 F .49(tem rolls the log forw)
-323.2 442.8 R .49(ard ag)-.1 F .49(ainst the database, reapply-)-.05 F
-.682(ing an)323.2 454.8 R 3.181(yc)-.15 G .681
-(hanges to on-disk pages that were in memory)-3.181 F .14
-(at the time of the crash.)323.2 466.8 R .14
-(Since the log contains pre- and)5.14 F .957
-(post-change state for transactions, the reco)323.2 478.8 R -.15(ve)-.15
-G .956(ry system).15 F 1.14(also uses the log to restore an)323.2 490.8
-R 3.64(yp)-.15 G 1.14(ages to their original)-3.64 F 1.615(state if the)
-323.2 502.8 R 4.115(yw)-.15 G 1.615
-(ere modi\214ed by transactions that ne)-4.115 F -.15(ve)-.25 G(r).15 E
-(committed.)323.2 514.8 Q 2.051
-(If the data disk is lost, the system administrator can)323.2 531 R .887
-(restore the most recent cop)323.2 543 R 3.386(yf)-.1 G .886
-(rom backup.)-3.386 F .886(The reco)5.886 F(v-)-.15 E 1.298
-(ery system will roll the entire log forw)323.2 555 R 1.298(ard ag)-.1 F
-1.298(ainst the)-.05 F 2.64
-(original database, reapplying all committed changes.)323.2 567 R 4.363
-(When it \214nishes, the database will contain e)323.2 579 R -.15(ve)
--.25 G(ry).15 E .535(change made by e)323.2 591 R -.15(ve)-.25 G .534
-(ry transaction that e).15 F -.15(ve)-.25 G 3.034(rc).15 G(ommitted.)
--3.034 E .494(If the log disk is lost, then the reco)323.2 607.2 R -.15
-(ve)-.15 G .495(ry system can use).15 F 1.853
-(the in-memory copies of log entries to roll back an)323.2 619.2 R(y)
--.15 E .026(uncommitted transactions, \215ush all in-memory database)
-323.2 631.2 R 1.659(pages to the data disk, and shut do)323.2 643.2 R
-1.659(wn gracefully)-.25 F 6.658(.A)-.65 G(t)-6.658 E 2.204
-(that point, the system administrator can back up the)323.2 655.2 R .039
-(database disk, install a ne)323.2 667.2 R 2.539(wl)-.25 G .039
-(og disk, and restart the sys-)-2.539 F(tem.)323.2 679.2 Q EP
-%%Page: 6 6
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 12/Times-Bold@0 SF 3(3.10.3. Checkpoints)79.2 84 R/F1 10
-/Times-Roman@0 SF(Berk)79.2 100.2 Q(ele)-.1 E 6.085(yD)-.15 G 6.085(Bi)
--6.085 G 3.585(ncludes a checkpointing service that)-6.085 F .263
-(interacts with the reco)79.2 112.2 R -.15(ve)-.15 G .263(ry system.).15
-F .263(During normal pro-)5.263 F 2.415
-(cessing, both the log and the database are changing)79.2 124.2 R
-(continually)79.2 136.2 Q 5.925(.A)-.65 G 3.425(ta)-5.925 G 1.224 -.15
-(ny g)-3.425 H -2.15 -.25(iv e).15 H 3.424(ni).25 G .924
-(nstant, the on-disk v)-3.424 F(ersions)-.15 E .414(of the tw)79.2 148.2
-R 2.914(oa)-.1 G .414(re not guaranteed to be consistent.)-2.914 F .414
-(The log)5.414 F 3.838
-(probably contains changes that are not yet in the)79.2 160.2 R
-(database.)79.2 172.2 Q .085(When an application mak)79.2 188.4 R .086
-(es a)-.1 F/F2 10/Times-Italic@0 SF -.15(ch)2.586 G(ec).15 E(kpoint)-.2
-E F1 2.586(,a)C .086(ll committed)-2.586 F .443
-(changes in the log up to that point are guaranteed to be)79.2 200.4 R
-.631(present on the data disk, too.)79.2 212.4 R .632
-(Checkpointing is moder)5.631 F(-)-.2 E .046(ately e)79.2 224.4 R
-(xpensi)-.15 E .346 -.15(ve d)-.25 H .046(uring normal processing, b).15
-F .045(ut limits the)-.2 F(time spent reco)79.2 236.4 Q -.15(ve)-.15 G
-(ring from crashes.).15 E 3.117
-(After an application or operating system crash, the)79.2 252.6 R(reco)
-79.2 264.6 Q -.15(ve)-.15 G 7.419(ry system only needs to go back tw).15
-F(o)-.1 E(checkpoints)79.2 278.6 Q/F3 7/Times-Roman@0 SF(1)-4 I F1 1.376
-(to start rolling the log forw)3.876 4 N 3.875(ard. W)-.1 F(ithout)-.4 E
-3.264(checkpoints, there is no w)79.2 290.6 R 3.265(ay to be sure ho)-.1
-F 5.765(wl)-.25 G(ong)-5.765 E .395(restarting after a crash will tak)
-79.2 302.6 R 2.895(e. W)-.1 F .395(ith checkpoints, the)-.4 F .088
-(restart interv)79.2 314.6 R .089(al can be \214x)-.25 F .089
-(ed by the programmer)-.15 F 5.089(.R)-.55 G(eco)-5.089 E(v-)-.15 E .668
-(ery processing can be guaranteed to complete in a sec-)79.2 326.6 R
-(ond or tw)79.2 338.6 Q(o.)-.1 E(Softw)79.2 354.8 Q 2.457
-(are crashes are much more common than disk)-.1 F -.1(fa)79.2 366.8 S
-3.385(ilures. Man).1 F 3.385(yd)-.15 G -2.15 -.25(ev e)-3.385 H .884
-(lopers w).25 F .884(ant to guarantee that soft-)-.1 F -.1(wa)79.2 378.8
-S .158(re b).1 F .158(ugs do not destro)-.2 F 2.658(yd)-.1 G .158
-(ata, b)-2.658 F .158(ut are willing to restore)-.2 F .631
-(from tape, and to tolerate a day or tw)79.2 390.8 R 3.131(oo)-.1 G
-3.131(fl)-3.131 G .63(ost w)-3.131 F .63(ork, in)-.1 F .89(the unlikle)
-79.2 402.8 R 3.39(ye)-.15 G -.15(ve)-3.64 G .89(nt of a disk crash.).15
-F -.4(Wi)5.89 G .89(th Berk).4 F(ele)-.1 E 3.39(yD)-.15 G(B,)-3.39 E
-1.093(programmers may truncate the log at checkpoints.)79.2 414.8 R(As)
-6.092 E .09(long as the tw)79.2 426.8 R 2.59(om)-.1 G .09
-(ost recent checkpoints are present, the)-2.59 F(reco)79.2 438.8 Q -.15
-(ve)-.15 G .106(ry system can guarantee that no committed trans-).15 F
-.611(actions are lost after a softw)79.2 450.8 R .611(are crash.)-.1 F
-.611(In this case, the)5.611 F(reco)79.2 462.8 Q -.15(ve)-.15 G 1.439
-(ry system does not require that the log and the).15 F 1.328
-(data be on separate de)79.2 474.8 R 1.329
-(vices, although separating them)-.25 F(can still impro)79.2 486.8 Q .3
--.15(ve p)-.15 H(erformance by spreading out writes.).15 E F0 3
-(3.10.4. T)79.2 516.8 R -.12(wo)-.888 G(-phase locking).12 E F1(Berk)
-79.2 533 Q(ele)-.1 E 4.416(yD)-.15 G 4.416(Bp)-4.416 G(ro)-4.416 E 1.916
-(vides a service kno)-.15 F 1.915(wn as tw)-.25 F(o-phase)-.1 E 3.017
-(locking. In)79.2 545 R .517(order to reduce the lik)3.017 F .518
-(elihood of deadlocks)-.1 F 2.547(and to guarantee A)79.2 557 R 2.546
-(CID properties, database systems)-.4 F .063(manage locks in tw)79.2 569
-R 2.564(op)-.1 G 2.564(hases. First,)-2.564 F .064(during the operation)
-2.564 F 1.574(of a transaction, the)79.2 581 R 4.074(ya)-.15 G 1.574
-(cquire locks, b)-4.074 F 1.573(ut ne)-.2 F -.15(ve)-.25 G 4.073(rr).15
-G(elease)-4.073 E 6.147(them. Second,)79.2 593 R 3.648
-(at the end of the transaction, the)6.147 F(y)-.15 E .235
-(release locks, b)79.2 605 R .235(ut ne)-.2 F -.15(ve)-.25 G 2.735(ra)
-.15 G .235(cquire them.)-2.735 F .235(In practice, most)5.235 F 4.69
-(database systems, including Berk)79.2 617 R(ele)-.1 E 7.19(yD)-.15 G
-4.69(B, acquire)-7.19 F 2.314(locks on demand o)79.2 629 R -.15(ve)-.15
-G 4.814(rt).15 G 2.314(he course of the transaction,)-4.814 F
-(then \215ush the log, then release all locks.)79.2 641 Q .32 LW 83.2
-650.6 79.2 650.6 DL 87.2 650.6 83.2 650.6 DL 91.2 650.6 87.2 650.6 DL
-95.2 650.6 91.2 650.6 DL 99.2 650.6 95.2 650.6 DL 103.2 650.6 99.2 650.6
-DL 107.2 650.6 103.2 650.6 DL 111.2 650.6 107.2 650.6 DL 115.2 650.6
-111.2 650.6 DL 119.2 650.6 115.2 650.6 DL 123.2 650.6 119.2 650.6 DL
-127.2 650.6 123.2 650.6 DL 131.2 650.6 127.2 650.6 DL 135.2 650.6 131.2
-650.6 DL 139.2 650.6 135.2 650.6 DL 143.2 650.6 139.2 650.6 DL 147.2
-650.6 143.2 650.6 DL 151.2 650.6 147.2 650.6 DL 155.2 650.6 151.2 650.6
-DL 159.2 650.6 155.2 650.6 DL 163.2 650.6 159.2 650.6 DL 167.2 650.6
-163.2 650.6 DL 171.2 650.6 167.2 650.6 DL 175.2 650.6 171.2 650.6 DL
-179.2 650.6 175.2 650.6 DL 183.2 650.6 179.2 650.6 DL 187.2 650.6 183.2
-650.6 DL 191.2 650.6 187.2 650.6 DL 195.2 650.6 191.2 650.6 DL 199.2
-650.6 195.2 650.6 DL 203.2 650.6 199.2 650.6 DL 207.2 650.6 203.2 650.6
-DL 211.2 650.6 207.2 650.6 DL 215.2 650.6 211.2 650.6 DL 219.2 650.6
-215.2 650.6 DL 223.2 650.6 219.2 650.6 DL/F4 5/Times-Roman@0 SF(1)100.8
-661 Q/F5 8/Times-Roman@0 SF .338(One checkpoint is not f)2.338 3.2 N
-.338(ar enough.)-.08 F .338(The reco)4.338 F -.12(ve)-.12 G .338
-(ry system can-).12 F .211
-(not be sure that the most recent checkpoint completed \212 it may ha)
-79.2 673.8 R -.12(ve)-.16 G .734
-(been interrupted by the crash that forced the reco)79.2 683.4 R -.12
-(ve)-.12 G .734(ry system to run).12 F(in the \214rst place.)79.2 693 Q
-F1(Berk)323.2 84 Q(ele)-.1 E 3.306(yD)-.15 G 3.306(Bc)-3.306 G .806
-(an lock entire database \214les, which cor)-3.306 F(-)-.2 E .845
-(respond to tables, or indi)323.2 96 R .844(vidual pages in them.)-.25 F
-.844(It does)5.844 F 2.141(no record-le)323.2 108 R -.15(ve)-.25 G 4.641
-(ll).15 G 4.641(ocking. By)-4.641 F 2.142(shrinking the page size,)4.641
-F(ho)323.2 120 Q(we)-.25 E -.15(ve)-.25 G 4.427 -.4(r, d).15 H -2.15
--.25(ev e).4 H 3.627(lopers can guarantee that e).25 F -.15(ve)-.25 G
-3.626(ry page).15 F 2.101(holds only a small number of records.)323.2
-132 R 2.102(This reduces)7.102 F(contention.)323.2 144 Q .388
-(If locking is enabled, then read and write operations on)323.2 160.2 R
-5.317(ad)323.2 172.2 S 2.817(atabase acquire tw)-5.317 F 2.817
-(o-phase locks, which are held)-.1 F 3.635
-(until the transaction completes.)323.2 184.2 R 3.635(Which objects are)
-8.635 F(lock)323.2 196.2 Q .738
-(ed and the order of lock acquisition depend on the)-.1 F -.1(wo)323.2
-208.2 S .503(rkload for each transaction.).1 F .502
-(It is possible for tw)5.502 F 3.002(oo)-.1 G(r)-3.002 E 1.315
-(more transactions to deadlock, so that each is w)323.2 220.2 R(aiting)
--.1 E(for a lock that is held by another)323.2 232.2 Q(.)-.55 E(Berk)
-323.2 248.4 Q(ele)-.1 E 3.307(yD)-.15 G 3.307(Bd)-3.307 G .807
-(etects deadlocks and automatically rolls)-3.307 F 1.825
-(back one of the transactions.)323.2 260.4 R 1.825
-(This releases the locks)6.825 F 1.926(that it held and allo)323.2 272.4
-R 1.925(ws the other transactions to con-)-.25 F 3.346(tinue. The)323.2
-284.4 R .847(caller is noti\214ed that its transaction did not)3.346 F
-1.747(complete, and may restart it.)323.2 296.4 R(De)6.747 E -.15(ve)
--.25 G 1.747(lopers can specify).15 F .646
-(the deadlock detection interv)323.2 308.4 R .647(al and the polic)-.25
-F 3.147(yt)-.15 G 3.147(ou)-3.147 G .647(se in)-3.147 F
-(choosing a transaction to roll back.)323.2 320.4 Q 6.686(The tw)323.2
-336.6 R 6.686(o-phase locking interf)-.1 F 6.686(aces are separately)-.1
-F .927(callable by applications that link Berk)323.2 348.6 R(ele)-.1 E
-3.427(yD)-.15 G .928(B, though)-3.427 F(fe)323.2 360.6 Q 5.64(wu)-.25 G
-3.14(sers ha)-5.64 F 3.44 -.15(ve n)-.2 H 3.14(eeded to use that f).15 F
-3.14(acility directly)-.1 F(.)-.65 E 2.211(Using these interf)323.2
-372.6 R 2.211(aces, Berk)-.1 F(ele)-.1 E 4.711(yD)-.15 G 4.712(Bp)-4.711
-G(ro)-4.712 E 2.212(vides a f)-.15 F(ast,)-.1 E 2.4
-(platform-portable locking system for general-purpose)323.2 384.6 R
-2.917(use. It)323.2 396.6 R .418
-(also lets users include non-database objects in a)2.917 F 3.497
-(database transaction, by controlling access to them)323.2 408.6 R -.15
-(ex)323.2 420.6 S(actly as if the).15 E 2.5(yw)-.15 G
-(ere inside the database.)-2.5 E .583(The Berk)323.2 436.8 R(ele)-.1 E
-3.083(yD)-.15 G 3.084(Bt)-3.083 G -.1(wo)-3.084 G .584(-phase locking f)
-.1 F .584(acility is b)-.1 F .584(uilt on)-.2 F .609(the f)323.2 448.8 R
-.609(astest correct locking primiti)-.1 F -.15(ve)-.25 G 3.108(st).15 G
-.608(hat are supported)-3.108 F 1.967(by the underlying architecture.)
-323.2 460.8 R 1.967(In the current imple-)6.967 F .593
-(mentation, this means that the locking system is dif)323.2 472.8 R(fer)
--.25 E(-)-.2 E 1.709(ent on the v)323.2 484.8 R 1.709
-(arious UNIX platforms, and is still more)-.25 F(dif)323.2 496.8 Q .695
-(ferent on W)-.25 F(indo)-.4 E .695(ws NT)-.25 F 5.695(.I)-.74 G 3.195
-(no)-5.695 G .695(ur e)-3.195 F .695(xperience, the most)-.15 F(dif)
-323.2 508.8 Q 2.634
-(\214cult aspect of performance tuning is \214nding the)-.25 F -.1(fa)
-323.2 520.8 S .883(stest locking primiti).1 F -.15(ve)-.25 G 3.383(st)
-.15 G .883(hat w)-3.383 F .882(ork correctly on a par)-.1 F(-)-.2 E 1.26
-(ticular architecture and then inte)323.2 532.8 R 1.26(grating the ne)
--.15 F 3.76(wi)-.25 G(nter)-3.76 E(-)-.2 E -.1(fa)323.2 544.8 S
-(ce with the se).1 E -.15(ve)-.25 G(ral that we already support.).15 E
-.536(The w)323.2 561 R .536(orld w)-.1 F .536
-(ould be a better place if the operating sys-)-.1 F 2.096
-(tems community w)323.2 573 R 2.096(ould uniformly implement POSIX)-.1 F
-1.31(locking primiti)323.2 585 R -.15(ve)-.25 G 3.81(sa).15 G 1.31(nd w)
--3.81 F 1.31(ould guarantee that acquiring)-.1 F 1.085
-(an uncontested lock w)323.2 597 R 1.085(as a f)-.1 F 1.085
-(ast operation.)-.1 F 1.085(Locks must)6.085 F -.1(wo)323.2 609 S 3.641
-(rk both among threads in a single process and).1 F(among processes.)
-323.2 621 Q F0 3(3.11. Concurr)323.2 651 R(ency)-.216 E F1 .383
-(Good performance under concurrent operation is a crit-)323.2 667.2 R
-.766(ical design point for Berk)323.2 679.2 R(ele)-.1 E 3.266(yD)-.15 G
-3.265(B. Although)-3.266 F(Berk)3.265 E(ele)-.1 E(y)-.15 E 1.961
-(DB is itself not multi-threaded, it is thread-safe, and)323.2 691.2 R
-.547(runs well in threaded applications.)323.2 703.2 R(Philosophically)
-5.546 E 3.046(,w)-.65 G(e)-3.046 E(vie)323.2 715.2 Q 4.764(wt)-.25 G
-2.264(he use of threads and the choice of a threads)-4.764 F EP
-%%Page: 7 7
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 10/Times-Roman@0 SF .066(package as a polic)79.2 84 R 2.566(yd)-.15
-G .065(ecision, and prefer to of)-2.566 F .065(fer mecha-)-.25 F .042
-(nism \(the ability to run threaded or not\), allo)79.2 96 R .043
-(wing appli-)-.25 F(cations to choose their o)79.2 108 Q(wn policies.)
--.25 E 1.947(The locking, logging, and b)79.2 124.2 R(uf)-.2 E 1.947
-(fer pool subsystems all)-.25 F .711
-(use shared memory or other OS-speci\214c sharing f)79.2 136.2 R(acili-)
--.1 E 1.713(ties to communicate.)79.2 148.2 R 1.713(Locks, b)6.713 F(uf)
--.2 E 1.713(fer pool fetches, and)-.25 F 1.061(log writes beha)79.2
-160.2 R 1.361 -.15(ve i)-.2 H 3.561(nt).15 G 1.061(he same w)-3.561 F
-1.061(ay across threads in a)-.1 F .033(single process as the)79.2 172.2
-R 2.532(yd)-.15 G 2.532(oa)-2.532 G .032(cross dif)-2.532 F .032
-(ferent processes on a)-.25 F(single machine.)79.2 184.2 Q .896
-(As a result, concurrent database applications may start)79.2 200.4 R
-1.651(up a ne)79.2 212.4 R 4.151(wp)-.25 G 1.651(rocess for e)-4.151 F
--.15(ve)-.25 G 1.651(ry single user).15 F 4.151(,m)-.4 G 1.651
-(ay create a)-4.151 F 2.848(single serv)79.2 224.4 R 2.848(er which spa)
--.15 F 2.849(wns a ne)-.15 F 5.349(wt)-.25 G 2.849(hread for e)-5.349 F
--.15(ve)-.25 G(ry).15 E(client request, or may choose an)79.2 236.4 Q
-2.5(yp)-.15 G(olic)-2.5 E 2.5(yi)-.15 G 2.5(nb)-2.5 G(etween.)-2.5 E
-(Berk)79.2 252.6 Q(ele)-.1 E 3.629(yD)-.15 G 3.629(Bh)-3.629 G 1.128
-(as been carefully designed to minimize)-3.629 F .07
-(contention and maximize concurrenc)79.2 264.6 R 3.87 -.65(y. T)-.15 H
-.07(he cache man-).65 F .57(ager allo)79.2 276.6 R .57
-(ws all threads or processes to bene\214t from I/O)-.25 F 2.917
-(done by one.)79.2 288.6 R 2.917(Shared resources must sometimes be)
-7.917 F(lock)79.2 300.6 Q 1.804(ed for e)-.1 F(xclusi)-.15 E 2.104 -.15
-(ve a)-.25 H 1.804(ccess by one thread of control.).15 F 1.757 -.8(We h)
-79.2 312.6 T -2.25 -.2(av e).8 H -.1(ke)2.857 G .158
-(pt critical sections small, and are careful not).1 F 1.199
-(to hold critical resource locks across system calls that)79.2 324.6 R
-.538(could deschedule the locking thread or process.)79.2 336.6 R
-(Sleep-)5.539 E .979(ycat Softw)79.2 348.6 R .979
-(are has customers with hundreds of concur)-.1 F(-)-.2 E(rent users w)
-79.2 360.6 Q(orking on a single database in production.)-.1 E/F1 12
-/Times-Bold@0 SF 3(4. Engineering)79.2 390.6 R(Philosoph)3 E(y)-.18 E F0
-(Fundamentally)79.2 406.8 Q 3.998(,B)-.65 G(erk)-3.998 E(ele)-.1 E 3.998
-(yD)-.15 G 3.998(Bi)-3.998 G 3.999(sac)-3.998 G 1.499
-(ollection of access)-3.999 F .19(methods with important f)79.2 418.8 R
-.19(acilities, lik)-.1 F 2.69(el)-.1 G .19(ogging, locking,)-2.69 F
-1.251(and transactional access underlying them.)79.2 430.8 R 1.252
-(In both the)6.252 F .992(research and the commercial w)79.2 442.8 R
-.991(orld, the techniques for)-.1 F -.2(bu)79.2 454.8 S 2.727
-(ilding systems lik).2 F 5.227(eB)-.1 G(erk)-5.227 E(ele)-.1 E 5.227(yD)
--.15 G 5.227(Bh)-5.227 G -2.25 -.2(av e)-5.227 H 2.728(been well-)5.427
-F(kno)79.2 466.8 Q(wn for a long time.)-.25 E .443(The k)79.2 483 R .743
--.15(ey a)-.1 H(dv).15 E .442(antage of Berk)-.25 F(ele)-.1 E 2.942(yD)
--.15 G 2.942(Bi)-2.942 G 2.942(st)-2.942 G .442(he careful atten-)-2.942
-F 1.059(tion that has been paid to engineering details through-)79.2 495
-R 1.039(out its life.)79.2 507 R 2.639 -.8(We h)6.039 H -2.25 -.2(av e)
-.8 H 1.039(carefully designed the system so)3.739 F .452
-(that the core f)79.2 519 R .452(acilities, lik)-.1 F 2.952(el)-.1 G
-.452(ocking and I/O, surf)-2.952 F .453(ace the)-.1 F .972(right interf)
-79.2 531 R .971(aces and are otherwise opaque to the caller)-.1 F(.)-.55
-E .294(As programmers, we understand the v)79.2 543 R .295
-(alue of simplicity)-.25 F .206(and ha)79.2 555 R .506 -.15(ve w)-.2 H
-(ork).05 E .206(ed hard to simplify the interf)-.1 F .205(aces we sur)
--.1 F(-)-.2 E -.1(fa)79.2 567 S(ce to users of the database system.).1 E
-(Berk)79.2 583.2 Q(ele)-.1 E 4.531(yD)-.15 G 4.531(Ba)-4.531 G -.2(vo)
--4.731 G 2.031(ids limits in the code.).2 F 2.031(It places no)7.031 F
-.474(practical limit on the size of k)79.2 595.2 R -.15(ey)-.1 G .473
-(s, v).15 F .473(alues, or databases;)-.25 F(the)79.2 607.2 Q 2.5(ym)
--.15 G(ay gro)-2.5 E 2.5(wt)-.25 G 2.5(oo)-2.5 G(ccup)-2.5 E 2.5(yt)-.1
-G(he a)-2.5 E -.25(va)-.2 G(ilable storage space.).25 E 1.857
-(The locking and logging subsystems ha)79.2 623.4 R 2.157 -.15(ve b)-.2
-H 1.858(een care-).15 F .184
-(fully crafted to reduce contention and impro)79.2 635.4 R .484 -.15
-(ve t)-.15 H(hrough-).15 E 2.16
-(put by shrinking or eliminating critical sections, and)79.2 647.4 R
-(reducing the sizes of lock)79.2 659.4 Q(ed re)-.1 E
-(gions and log entries.)-.15 E 2.238
-(There is nothing in the design or implementation of)79.2 675.6 R(Berk)
-79.2 687.6 Q(ele)-.1 E 2.818(yD)-.15 G 2.818(Bt)-2.818 G .318
-(hat pushes the state of the art in database)-2.818 F 3.545
-(systems. Rather)79.2 699.6 R 3.545(,w)-.4 G 3.545(eh)-3.545 G -2.25 -.2
-(av e)-3.545 H 1.044(been v)3.745 F 1.044(ery careful to get the)-.15 F
-4.321(engineering right.)79.2 711.6 R 4.321
-(The result is a system that is)9.321 F(superior)323.2 84 Q 2.867(,a)-.4
-G 2.867(sa)-2.867 G 2.866(ne)-2.867 G .366
-(mbedded database system, to an)-2.866 F 2.866(yo)-.15 G(ther)-2.866 E
-(solution a)323.2 96 Q -.25(va)-.2 G(ilable.).25 E .811
-(Most database systems trade of)323.2 112.2 R 3.312(fs)-.25 G .812
-(implicity for correct-)-3.312 F 4.151(ness. Either)323.2 124.2 R 1.651
-(the system is easy to use, or it supports)4.151 F 1.17
-(concurrent use and survi)323.2 136.2 R -.15(ve)-.25 G 3.67(ss).15 G
-1.17(ystem f)-3.67 F 3.67(ailures. Berk)-.1 F(ele)-.1 E(y)-.15 E 1.013
-(DB, because of its careful design and implementation,)323.2 148.2 R(of)
-323.2 160.2 Q(fers both simplicity and correctness.)-.25 E .759
-(The system has a small footprint, mak)323.2 176.4 R .759
-(es simple opera-)-.1 F 1.012
-(tions simple to carry out \(inserting a ne)323.2 188.4 R 3.512(wr)-.25
-G 1.012(ecord tak)-3.512 F(es)-.1 E 1.16(just a fe)323.2 200.4 R 3.66
-(wl)-.25 G 1.16(ines of code\), and beha)-3.66 F -.15(ve)-.2 G 3.66(sc)
-.15 G 1.16(orrectly in the)-3.66 F -.1(fa)323.2 212.4 S .528(ce of hea)
-.1 F .527(vy concurrent use, system crashes, and e)-.2 F -.15(ve)-.25 G
-(n).15 E(catastrophic f)323.2 224.4 Q(ailures lik)-.1 E 2.5(el)-.1 G
-(oss of a hard disk.)-2.5 E F1 3(5. The)323.2 254.4 R(Berk)3 E
-(eley DB 2.x Distrib)-.12 E(ution)-.24 E F0(Berk)323.2 270.6 Q(ele)-.1 E
-4.171(yD)-.15 G 4.171(Bi)-4.171 G 4.171(sd)-4.171 G(istrib)-4.171 E
-1.671(uted in source code form from)-.2 F/F2 10/Times-Italic@0 SF(www)
-323.2 282.6 Q(.sleepycat.com)-.74 E F0 7.322(.U)C 2.322
-(sers are free to do)-7.322 F 2.321(wnload and)-.25 F -.2(bu)323.2 294.6
-S(ild the softw).2 E(are, and to use it in their applications.)-.1 E F1
-3(5.1. What)323.2 324.6 R(is in the distrib)3 E(ution)-.24 E F0 4.827
-(The distrib)323.2 340.8 R 4.827(ution is a compressed archi)-.2 F 5.127
--.15(ve \214)-.25 H 7.328(le. It).15 F .057
-(includes the source code for the Berk)323.2 352.8 R(ele)-.1 E 2.556(yD)
--.15 G 2.556(Bl)-2.556 G(ibrary)-2.556 E 2.556(,a)-.65 G(s)-2.556 E .453
-(well as documentation, test suites, and supporting utili-)323.2 364.8 R
-(ties.)323.2 376.8 Q 2.613(The source code includes b)323.2 393 R 2.612
-(uild support for all sup-)-.2 F .254(ported platforms.)323.2 405 R .254
-(On UNIX systems Berk)5.254 F(ele)-.1 E 2.755(yD)-.15 G 2.755(Bu)-2.755
-G(ses)-2.755 E 1.28(the GNU autocon\214guration tool,)323.2 417 R/F3 10
-/Courier@0 SF(autoconf)3.78 E F0 3.78(,t)C 3.78(oi)-3.78 G(den-)-3.78 E
-.992(tify the system and to b)323.2 429 R .992
-(uild the library and supporting)-.2 F 3.589(utilities. Berk)323.2 441 R
-(ele)-.1 E 3.589(yD)-.15 G 3.588(Bi)-3.589 G 1.088(ncludes speci\214c b)
--3.588 F 1.088(uild en)-.2 F(viron-)-.4 E .515
-(ments for other platforms, such as VMS and W)323.2 453 R(indo)-.4 E
-(ws.)-.25 E F1 3(5.1.1. Documentation)323.2 483 R F0 5.008(The distrib)
-323.2 499.2 R 5.008(uted system includes documentation in)-.2 F 1.626
-(HTML format.)323.2 511.2 R 1.626(The documentation is in tw)6.626 F
-4.127(op)-.1 G 1.627(arts: a)-4.127 F .725
-(UNIX-style reference manual for use by programmers,)323.2 523.2 R
-(and a reference guide which is tutorial in nature.)323.2 535.2 Q F1 3
-(5.1.2. T)323.2 565.2 R(est suite)-1.104 E F0 1.107(The softw)323.2
-581.4 R 1.108(are also includes a complete test suite, writ-)-.1 F .155
-(ten in Tcl.)323.2 593.4 R 1.754 -.8(We b)5.154 H(elie).8 E .454 -.15
-(ve t)-.25 H .154(hat the test suite is a k).15 F .454 -.15(ey a)-.1 H
-(dv).15 E(an-)-.25 E(tage of Berk)323.2 605.4 Q(ele)-.1 E 2.5(yD)-.15 G
-2.5(Bo)-2.5 G -.15(ve)-2.65 G 2.5(rc).15 G(omparable systems.)-2.5 E
-2.612(First, the test suite allo)323.2 621.6 R 2.613(ws users who do)
--.25 F 2.613(wnload and)-.25 F -.2(bu)323.2 633.6 S 1.731(ild the softw)
-.2 F 1.731(are to be sure that it is operating cor)-.1 F(-)-.2 E(rectly)
-323.2 645.6 Q(.)-.65 E .893(Second, the test suite allo)323.2 661.8 R
-.894(ws us, lik)-.25 F 3.394(eo)-.1 G .894(ther commercial)-3.394 F(de)
-323.2 673.8 Q -.15(ve)-.25 G .536(lopers of database softw).15 F .536
-(are, to e)-.1 F -.15(xe)-.15 G .535(rcise the system).15 F 2.256
-(thoroughly at e)323.2 685.8 R -.15(ve)-.25 G 2.256(ry release.).15 F
-2.256(When we learn of ne)7.256 F(w)-.25 E -.2(bu)323.2 697.8 S 1.719
-(gs, we add them to the test suite.).2 F 3.319 -.8(We r)6.719 H 1.719
-(un the test).8 F 5.692(suite continually during de)323.2 709.8 R -.15
-(ve)-.25 G 5.692(lopment c).15 F 5.692(ycles, and)-.15 F EP
-%%Page: 8 8
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 10/Times-Roman@0 SF(al)79.2 84 Q -.1(wa)-.1 G .314
-(ys prior to release.).1 F .314(The result is a much more reli-)5.314 F
-(able system by the time it reaches beta release.)79.2 96 Q/F1 12
-/Times-Bold@0 SF 3(5.2. Binary)79.2 126 R(distrib)3 E(ution)-.24 E F0
-(Sleep)79.2 142.2 Q .893(ycat mak)-.1 F .893
-(es compiled libraries and general binary)-.1 F(distrib)79.2 154.2 Q
-(utions a)-.2 E -.25(va)-.2 G(ilable to customers for a fee.).25 E F1 3
-(5.3. Supported)79.2 184.2 R(platf)3 E(orms)-.3 E F0(Berk)79.2 200.4 Q
-(ele)-.1 E 5.623(yD)-.15 G 5.623(Br)-5.623 G 3.123(uns on an)-5.623 F
-5.622(yo)-.15 G 3.122(perating system with a)-5.622 F .816
-(POSIX 1003.1 interf)79.2 212.4 R .817(ace [IEEE96], which includes vir)
--.1 F(-)-.2 E 1.998(tually e)79.2 224.4 R -.15(ve)-.25 G 1.997
-(ry UNIX system.).15 F 1.997(In addition, the softw)6.997 F(are)-.1 E
-2.85(runs on VMS, W)79.2 236.4 R(indo)-.4 E 2.85(ws/95, W)-.25 F(indo)
--.4 E 2.85(ws/98, and W)-.25 F(in-)-.4 E(do)79.2 248.4 Q(ws/NT)-.25 E
-10.21(.S)-.74 G(leep)-10.21 E 5.21(ycat Softw)-.1 F 5.21
-(are no longer supports)-.1 F(deplo)79.2 260.4 Q(yment on sixteen-bit W)
--.1 E(indo)-.4 E(ws systems.)-.25 E F1 3(6. Berk)79.2 290.4 R
-(eley DB 2.x Licensing)-.12 E F0(Berk)79.2 306.6 Q(ele)-.1 E 2.627(yD)
--.15 G 2.627(B2)-2.627 G .128(.x is distrib)-2.627 F .128
-(uted as an Open Source prod-)-.2 F 4.709(uct. The)79.2 318.6 R(softw)
-4.709 E 2.209(are is freely a)-.1 F -.25(va)-.2 G 2.209
-(ilable from us at our).25 F -.8(We)79.2 330.6 S 3.372(bs).8 G .872
-(ite, and in other media.)-3.372 F .872(Users are free to do)5.872 F
-(wn-)-.25 E(load the softw)79.2 342.6 Q(are and b)-.1 E
-(uild applications with it.)-.2 E 1.023(The 1.x v)79.2 358.8 R 1.022
-(ersions of Berk)-.15 F(ele)-.1 E 3.522(yD)-.15 G 3.522(Bw)-3.522 G
-1.022(ere co)-3.522 F -.15(ve)-.15 G 1.022(red by the).15 F 3.763
-(UC Berk)79.2 370.8 R(ele)-.1 E 6.263(yc)-.15 G(op)-6.263 E 3.763
-(yright that co)-.1 F -.15(ve)-.15 G 3.764(rs softw).15 F 3.764
-(are freely)-.1 F(redistrib)79.2 382.8 Q 1.742(utable in source form.)
--.2 F 1.741(When Sleep)6.742 F 1.741(ycat Soft-)-.1 F -.1(wa)79.2 394.8
-S .906(re w).1 F .907(as formed, we needed to draft a license consis-)
--.1 F 2.319(tent with the cop)79.2 406.8 R 2.319(yright go)-.1 F -.15
-(ve)-.15 G 2.318(rning the e).15 F 2.318(xisting, older)-.15 F(softw)
-79.2 418.8 Q 5.328(are. Because)-.1 F 2.828(of important dif)5.328 F
-2.828(ferences between)-.25 F .497(the UC Berk)79.2 430.8 R(ele)-.1 E
-2.997(yc)-.15 G(op)-2.997 E .497(yright and the GPL, it w)-.1 F .496
-(as impos-)-.1 F .884(sible for us to use the GPL.)79.2 442.8 R 3.384
-(As)5.884 G .884(econd cop)-3.384 F .884(yright, with)-.1 F .87
-(terms contradictory to the \214rst, simply w)79.2 454.8 R .87
-(ould not ha)-.1 F -.15(ve)-.2 G -.1(wo)79.2 466.8 S(rk).1 E(ed.)-.1 E
-(Sleep)79.2 483 Q 2.533(ycat w)-.1 F 2.533
-(anted to continue Open Source de)-.1 F -.15(ve)-.25 G(lop-).15 E 2.079
-(ment of Berk)79.2 495 R(ele)-.1 E 4.579(yD)-.15 G 4.579(Bf)-4.579 G
-2.079(or se)-4.579 F -.15(ve)-.25 G 2.079(ral reasons.).15 F 3.678 -.8
-(We a)7.078 H(gree).8 E .853
-(with Raymond [Raym98] and others that Open Source)79.2 507 R(softw)79.2
-519 Q .763(are is typically of higher quality than proprietary)-.1 F(,)
--.65 E 2.616(binary-only products.)79.2 531 R 2.617
-(Our customers bene\214t from a)7.616 F .983(community of de)79.2 543 R
--.15(ve)-.25 G .983(lopers who kno).15 F 3.483(wa)-.25 G .983
-(nd use Berk)-3.483 F(ele)-.1 E(y)-.15 E 1.317
-(DB, and can help with application design, deb)79.2 555 R(ugging,)-.2 E
-1.65(and performance tuning.)79.2 567 R -.4(Wi)6.65 G 1.65
-(despread distrib).4 F 1.65(ution and)-.2 F 1.017
-(use of the source code tends to isolate b)79.2 579 R 1.017(ugs early)
--.2 F 3.517(,a)-.65 G(nd)-3.517 E .032(to get \214x)79.2 591 R .031
-(es back into the distrib)-.15 F .031(uted system quickly)-.2 F 5.031
-(.A)-.65 G(s)-5.031 E 3.553(ar)79.2 603 S 1.053(esult, Berk)-3.553 F
-(ele)-.1 E 3.553(yD)-.15 G 3.553(Bi)-3.553 G 3.553(sm)-3.553 G 1.053
-(ore reliable.)-3.553 F 1.054(Just as impor)6.054 F(-)-.2 E(tantly)79.2
-615 Q 3.695(,i)-.65 G(ndi)-3.695 E 1.195
-(vidual users are able to contrib)-.25 F 1.195(ute ne)-.2 F 3.695(wf)
--.25 G(ea-)-3.695 E 1.056
-(tures and performance enhancements, to the bene\214t of)79.2 627 R
--2.15 -.25(ev e)79.2 639 T .359(ryone who uses Berk).25 F(ele)-.1 E
-2.859(yD)-.15 G 2.859(B. From)-2.859 F 2.858(ab)2.859 G .358
-(usiness per)-3.058 F(-)-.2 E(specti)79.2 651 Q -.15(ve)-.25 G 3.115(,O)
-.15 G .615(pen Source and free distrib)-3.115 F .615(ution of the soft-)
--.2 F -.1(wa)79.2 663 S 1.605(re creates share for us, and gi).1 F -.15
-(ve)-.25 G 4.105(su).15 G 4.105(sam)-4.105 G(ark)-4.105 E 1.605(et into)
--.1 F .412(which we can sell products and services.)79.2 675 R(Finally)
-5.413 E 2.913(,m)-.65 G(ak-)-2.913 E .148(ing the source code freely a)
-79.2 687 R -.25(va)-.2 G .147(ilable reduces our support).25 F 2.436
-(load, since customers can \214nd and \214x b)79.2 699 R 2.437
-(ugs without)-.2 F(recourse to us, in man)79.2 711 Q 2.5(yc)-.15 G
-(ases.)-2.5 E 4.727 -.8(To p)323.2 84 T(reserv).8 E 5.627(et)-.15 G
-3.126(he Open Source heritage of the older)-5.627 F(Berk)323.2 96 Q(ele)
--.1 E 3.003(yD)-.15 G 3.003(Bc)-3.003 G .504(ode, we drafted a ne)-3.003
-F 3.004(wl)-.25 G .504(icense go)-3.004 F -.15(ve)-.15 G(rning).15 E
-.417(the distrib)323.2 108 R .417(ution of Berk)-.2 F(ele)-.1 E 2.916
-(yD)-.15 G 2.916(B2)-2.916 G 2.916(.x. W)-2.916 F 2.916(ea)-.8 G .416
-(dopted terms)-2.916 F .411(from the GPL that mak)323.2 120 R 2.911(ei)
--.1 G 2.911(ti)-2.911 G .411(mpossible to turn our Open)-2.911 F 1.289
-(Source code into proprietary code o)323.2 132 R 1.288(wned by someone)
--.25 F(else.)323.2 144 Q(Brie\215y)323.2 160.2 Q 3.18(,t)-.65 G .68
-(he terms go)-3.18 F -.15(ve)-.15 G .68(rning the use and distrib).15 F
-.68(ution of)-.2 F(Berk)323.2 172.2 Q(ele)-.1 E 2.5(yD)-.15 G 2.5(Ba)
--2.5 G(re:)-2.5 E/F2 8/Times-Roman@0 SF<83>328.2 188.4 Q F0
-(your application must be internal to your site, or)17.2 E F2<83>328.2
-204.6 Q F0 .612(your application must be freely redistrib)17.2 F .611
-(utable in)-.2 F(source form, or)348.2 216.6 Q F2<83>328.2 232.8 Q F0
-(you must get a license from us.)17.2 E -.15(Fo)323.2 249 S 2.631(rc).15
-G .131(ustomers who prefer not to distrib)-2.631 F .132(ute Open Source)
--.2 F 1.493(products, we sell licenses to use and e)323.2 261 R 1.492
-(xtend Berk)-.15 F(ele)-.1 E(y)-.15 E(DB at a reasonable cost.)323.2 273
-Q 2.675 -.8(We w)323.2 289.2 T 1.076
-(ork hard to accommodate the needs of the Open).7 F .606
-(Source community)323.2 301.2 R 5.606(.F)-.65 G .606(or e)-5.756 F .606
-(xample, we ha)-.15 F .905 -.15(ve c)-.2 H .605(rafted spe-).15 F 1.415
-(cial licensing arrangements with Gnome to encourage)323.2 313.2 R
-(its use and distrib)323.2 325.2 Q(ution of Berk)-.2 E(ele)-.1 E 2.5(yD)
--.15 G(B.)-2.5 E(Berk)323.2 341.4 Q(ele)-.1 E 4.103(yD)-.15 G 4.103(Bc)
--4.103 G 1.603(onforms to the Open Source de\214nition)-4.103 F 4.867
-([Open99]. The)323.2 353.4 R 2.367
-(license has been carefully crafted to)4.867 F -.1(ke)323.2 365.4 S .643
-(ep the product a).1 F -.25(va)-.2 G .642(ilable as an Open Source of)
-.25 F(fering,)-.25 E(while pro)323.2 377.4 Q
-(viding enough of a return on our in)-.15 E -.15(ve)-.4 G(stment to).15
-E 1.546(fund continued de)323.2 389.4 R -.15(ve)-.25 G 1.546
-(lopment and support of the prod-).15 F 3.033(uct. The)323.2 401.4 R
-.534(current license has created a b)3.033 F .534(usiness capable)-.2 F
-.916(of funding three years of de)323.2 413.4 R -.15(ve)-.25 G .916
-(lopment on the softw).15 F(are)-.1 E(that simply w)323.2 425.4 Q
-(ould not ha)-.1 E .3 -.15(ve h)-.2 H(appened otherwise.).15 E F1 3
-(7. Summary)323.2 455.4 R F0(Berk)323.2 471.6 Q(ele)-.1 E 2.991(yD)-.15
-G 2.991(Bo)-2.991 G -.25(ff)-2.991 G .491
-(ers a unique collection of features, tar).25 F(-)-.2 E .175
-(geted squarely at softw)323.2 483.6 R .174(are de)-.1 F -.15(ve)-.25 G
-.174(lopers who need simple,).15 F .492
-(reliable database management services in their applica-)323.2 495.6 R
-5.3(tions. Good)323.2 507.6 R 2.8(design and implementation and careful)
-5.3 F 1.633(engineering throughout mak)323.2 519.6 R 4.133(et)-.1 G
-1.633(he softw)-4.133 F 1.634(are better than)-.1 F(man)323.2 531.6 Q
-2.5(yo)-.15 G(ther systems.)-2.5 E(Berk)323.2 547.8 Q(ele)-.1 E 4.1(yD)
--.15 G 4.1(Bi)-4.1 G 4.1(sa)-4.1 G 4.1(nO)-4.1 G 1.6
-(pen Source product, a)-4.1 F -.25(va)-.2 G 1.6(ilable at).25 F/F3 10
-/Times-Italic@0 SF(www)323.2 559.8 Q(.sleepycat.com)-.74 E F0 .654
-(for do)3.154 F 3.154(wnload. The)-.25 F(distrib)3.154 E .654(uted sys-)
--.2 F .383(tem includes e)323.2 571.8 R -.15(ve)-.25 G .383
-(rything needed to b).15 F .382(uild and deplo)-.2 F 2.882(yt)-.1 G(he)
--2.882 E(softw)323.2 583.8 Q(are or to port it to ne)-.1 E 2.5(ws)-.25 G
-(ystems.)-2.5 E(Sleep)323.2 600 Q 2.633(ycat Softw)-.1 F 2.633
-(are distrib)-.1 F 2.633(utes Berk)-.2 F(ele)-.1 E 5.133(yD)-.15 G 5.134
-(Bu)-5.133 G 2.634(nder a)-5.134 F .764(license agreement that dra)323.2
-612 R .764(ws on both the UC Berk)-.15 F(ele)-.1 E(y)-.15 E(cop)323.2
-624 Q 2.377(yright and the GPL.)-.1 F 2.377(The license guarantees that)
-7.377 F(Berk)323.2 636 Q(ele)-.1 E 3.384(yD)-.15 G 3.384(Bw)-3.384 G
-.884(ill remain an Open Source product and)-3.384 F(pro)323.2 648 Q
-1.493(vides Sleep)-.15 F 1.493(ycat with opportunities to mak)-.1 F
-3.994(em)-.1 G(one)-3.994 E(y)-.15 E(to fund continued de)323.2 660 Q
--.15(ve)-.25 G(lopment on the softw).15 E(are.)-.1 E EP
-%%Page: 9 9
-%%BeginPageSetup
-BP
-%%EndPageSetup
-/F0 12/Times-Bold@0 SF 3(8. Refer)79.2 84 R(ences)-.216 E/F1 10
-/Times-Roman@0 SF([Come79])79.2 100.2 Q(Comer)104.2 112.2 Q 3.127(,D)-.4
-G .627(., \231The Ubiquitous B-tree,)-3.127 F<9a>-.7 E/F2 10
-/Times-Italic@0 SF -.3(AC)3.126 G 3.126(MC).3 G(om-)-3.126 E .404
-(puting Surve)104.2 124.2 R(ys)-.3 E F1 -1.29(Vo)2.904 G .404
-(lume 11, number 2, June 1979.)1.29 F([Gray93])79.2 140.4 Q(Gray)104.2
-152.4 Q 2.982(,J)-.65 G .482(., and Reuter)-2.982 F 2.982(,A)-.4 G(.,)
--2.982 E F2 -1.55 -.55(Tr a)2.981 H .481(nsaction Pr).55 F(ocessing:)
--.45 E 6.776(Concepts and T)104.2 164.4 R(ec)-.92 E(hniques)-.15 E F1
-9.277(,M)C(or)-9.277 E -.05(ga)-.18 G(n-Kaufman).05 E(Publishers, 1993.)
-104.2 176.4 Q([IEEE96])79.2 192.6 Q .364
-(Institute for Electrical and Electronics Engineers,)104.2 204.6 R F2
-(IEEE/ANSI Std 1003.1)104.2 216.6 Q F1 2.5(,1)C(996 Edition.)-2.5 E
-([Litw80])79.2 232.8 Q 2.365(Litwin, W)104.2 244.8 R 2.366
-(., \231Linear Hashing: A Ne)-.92 F 4.866(wT)-.25 G 2.366(ool for)-5.666
-F 1.784(File and T)104.2 256.8 R 1.783(able Addressing,)-.8 F<9a>-.7 E
-F2(Pr)4.283 E 1.783(oceedings of the)-.45 F 4.804
-(6th International Confer)104.2 268.8 R 4.804(ence on V)-.37 F 4.804
-(ery Lar)-1.11 F -.1(ge)-.37 G 1.983(Databases \(VLDB\))104.2 280.8 R F1
-4.483(,M)C 1.982(ontreal, Quebec, Canada,)-4.483 F(October 1980.)104.2
-292.8 Q([Open94])79.2 309 Q 4.068(The Open Group,)104.2 321 R F2
-(Distrib)6.568 E 4.069(uted TP: The XA+)-.2 F .78(Speci\214cation, V)
-104.2 333 R(er)-1.11 E .78(sion 2)-.1 F F1 3.28(,T)C .78
-(he Open Group, 1994.)-3.28 F([Open99])79.2 349.2 Q(Opensource.or)104.2
-361.2 Q 8.307(g, \231Open Source De\214nition,)-.18 F<9a>-.7 E F2(www)
-104.2 373.2 Q(.opensour)-.74 E(ce)-.37 E(.or)-.15 E(g/osd.html)-.37 E F1
-3.13(,v)C .63(ersion 1.4, 1999.)-3.28 F([Raym98])79.2 389.4 Q .718
-(Raymond, E.S., \231The Cathedral and the Bazaar)104.2 401.4 R -.7<2c9a>
--.4 G F2(www)104.2 413.4 Q(.tuxedo.or)-.74 E(g/~esr/writings/cathedr)
--.37 E(al-)-.15 E(bazaar/cathedr)104.2 425.4 Q(al-bazaar)-.15 E(.html)
--1.11 E F1 2.5(,J)C(anuary 1998.)-2.5 E([Selt91])79.2 441.6 Q(Seltzer)
-104.2 453.6 Q 2.578(,M)-.4 G .078(., and Y)-2.578 F .079(igit, O., \231)
--.55 F 2.579(AN)-.8 G .579 -.25(ew H)-2.579 H .079(ashing P).25 F(ack-)
--.15 E 6.704(age for UNIX,)104.2 465.6 R<9a>-.7 E F2(Pr)9.204 E 6.704
-(oceedings 1991 W)-.45 F(inter)-.55 E(USENIX Confer)104.2 477.6 Q(ence)
--.37 E F1 2.5(,D)C(allas, TX, January 1991.)-2.5 E([Selt92])79.2 493.8 Q
-(Seltzer)104.2 505.8 Q 5.365(,M)-.4 G 2.865
-(., and Olson, M., \231LIBTP: Portable)-5.365 F 2.845(Modular T)104.2
-517.8 R 2.845(ransactions for UNIX,)-.35 F<9a>-.7 E F2(Pr)5.345 E
-(oceedings)-.45 E 1.49(1992 W)104.2 529.8 R 1.49(inter Usenix Confer)
--.55 F(ence)-.37 E F1 3.99(,S)C 1.49(an Francisco,)-3.99 F
-(CA, January 1992.)104.2 541.8 Q([Ston82])79.2 558 Q(Stonebrak)104.2 570
-Q(er)-.1 E 10.04(,M)-.4 G 7.54(., Stettner)-10.04 F 10.04(,H)-.4 G 7.54
-(., Kalash, J.,)-10.04 F .763(Guttman, A., and L)104.2 582 R .764
-(ynn, N., \231Document Process-)-.55 F .557
-(ing in a Relational Database System,)104.2 594 R 3.056<9a4d>-.7 G
-(emoran-)-3.056 E .825(dum No. UCB/ERL M82/32, Uni)104.2 606 R -.15(ve)
--.25 G .825(rsity of Cali-).15 F(fornia at Berk)104.2 618 Q(ele)-.1 E
-1.3 -.65(y, B)-.15 H(erk).65 E(ele)-.1 E 1.3 -.65(y, C)-.15 H
-(A, May 1982.).65 E EP
-%%Trailer
-end
-%%EOF
diff --git a/bdb/docs/ref/refs/embedded.html b/bdb/docs/ref/refs/embedded.html
deleted file mode 100644
index b7641d931c1..00000000000
--- a/bdb/docs/ref/refs/embedded.html
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-
-[Come79]
-
-
-
-
-
-[Gray93]
-
-
-
-
-
-
-[IEEE96]
-
-
-
-
-
-
-[Litw80]
-
-
-
-
-
-
-[Open94]
-
-
-
-
-
-
-[Open99]
-
-
-
-
-
-
-[Raym98]
-
-
-
-
-
-
-[Selt91]
-
-
-
-
-
-
-[Selt92]
-
-
-
-
-
-
-[Ston82]
-
-
-
-Challenges in Embedded Database System Administration
-Margo Seltzer, Harvard University
-Michael Olson, Sleepycat Software, Inc.
-{margo,mao}@sleepycat.com
-1. Introduction
-
-Embedded systems provide a combination of opportunities and challenges
-in application and system configuration and management.
-As an embedded system is most often dedicated to a single application or
-small set of tasks, the operating conditions of the system are
-typically better understood than those of general purpose computing
-environments.
-Similarly, as embedded systems are dedicated to a small set of tasks,
-one would expect that the software to manage them should be small
-and simple.
-On the other hand, once an embedded system is deployed, it must
-continue to function without interruption and without administrator
-intervention.
-2. Embedded Database Requirements
-Historically, much of the commercial database industry has been driven
-by the requirements of high performance online transaction
-processing (OLTP), complex query processing, and the industry
-standard benchmarks that have emerged (e.g., TPC-C [9],
-TPC-D [10]) to
-allow for system comparisons.
-As embedded systems typically perform fairly simple queries,
-such metrics are not nearly as relevant for embedded database
-systems as are ease of maintenance, robustness, and small footprint.
-Of these three requirements, robustness and ease of maintenance
-are the key issues.
-Users must trust the data stored in their devices and must not need
-to manually perform anything resembling system administration in order
-to get their unit to work properly.
-Fortunately, ease of use and robustness are important side
-effects of simplicity and good design.
-These, in turn, lead to a small size, providing the third
-requirement of an embedded system.
-2.1 The User Perspective
-2.2 The Developer Perspective
-3. Berkeley DB: A Database for Embedded Systems
-Berkeley DB is the result of implementing database functionality
-using the UNIX tool-based philosophy.
-The current Berkeley DB package, as distributed by Sleepycat
-Software, is a descendant of the hash and btree access methods
-distributed with 4.4BSD and its descendents.
-The original package (referred to as DB-1.85),
-while intended as a public domain replacement for dbm and
-its followers (e.g., ndbm, gdbm, etc), rapidly became widely
-used as an efficient, easy-to-use data store.
-It was incorporated into a number of Open Source packages including
-Perl, Sendmail, Kerberos, and the GNU C-library.
-4. Extensions for Embedded Environments
-While the Berkeley DB library has been designed for use in
-embedded systems, all the features described above are useful
-in more conventional systems as well.
-In this section, we discuss a number of features and "automatic
-knobs" that are specifically geared
-toward the more constrained environments found in gizmo databases.
-
-4.1 Automatic compression
-Following the programmatic interface design philosophy, we
-support application-specific (or default) compression routines.
-These can be geared toward the particular data types present
-in the application's dataset, thus providing better compression
-than a general purpose routine.
-Note that the application could instead specify an encryption
-function and create encrypted databases instead of compressed ones.
-Alternately, the application might specify a function that performs
-both compression and encryption.
-4.2 In-memory logging & transactions
-One of the four key properties of transaction systems is durability.
-This means that transaction systems are designed for permanent storage
-(most commonly disk). However, as mentioned above, embedded systems
-do not necessarily contain any such storage.
-Nevertheless, transactions can be useful in this environment to
-preserve the semantic integrity of the underlying storage.
-Berkeley DB optionally provides logging functionality and
-transaction support regardless of whether the database and logs
-are on disk or in memory.
-
-4.3 Remote Logs
-While we do not expect users to backup their television sets and
-toasters, it is conceivable that a set-top box provided by a
-cable carrier should, in fact, be backed up by that cable carrier.
-The ability to store logs remotely can provide "information appliance"
-functionality, and can also be used in conjunction with local logs
-to enhance reliability.
-Furthermore, remote logs provide for catastrophic recovery, e.g., loss
-of the gizmo, destruction of the gizmo, etc.
-
-4.4 Application References to Database Buffers
-
-Typically, when data is returned to the user, it must be copied
-from the data manager's buffer cache (or data page) into the
-application's memory.
-However, in an embedded environment, the robustness of the
-total software package is of paramount importance, not the
-isolation between the application and the data manager.
-As a result, it is possible for the data manager to avoid
-copies by giving applications direct references to data items
-in a shared memory cache.
-This is a significant performance optimization that can be
-allowed when the application and data manager are tightly
-integrated.
-
-4.5 Recoverable database creation/deletion
-
-In a conventional database management system, the creation of
-database tables (relations) and indices are heavyweight operations
-that are not recoverable.
-This is not acceptable in a complex embedded environment where
-instantaneous recovery and robust operation in the face of
-all types of database operations is essential.
-While Berkeley DB files can be removed using normal file system
-utilities, we provide transaction protected utilities that
-allow us to recover both database creation and deletion.
-
-4.6 Adaptive concurrency control
-The Berkeley DB package uses page-level locking by default.
-This trades off fine grain concurrency control for simplicity
-during recovery. (Finer grain concurrency control can be
-obtained by reducing the page size in the database.)
-However, when multiple threads/processes perform page-locking
-in the presence of writing operations, there is the
-potential for deadlock.
-As some environments do not need or desire the overhead of
-logging and transactions, it is important to provide the
-ability for concurrent access without the potential for
-deadlock.
-4.7 Adaptive synchronization
-
-In addition to the logical locks that protect the integrity of the
-database pages, Berkeley DB must synchronize access to shared memory
-data structures, such as the lock table, in-memory buffer pool, and
-in-memory log buffer.
-Each independent module uses a single mutex to protect its shared
-data structures, under the assumption that operations that require
-the mutex are very short and the potential for conflict is
-low.
-Unfortunately, in highly concurrent environments with multiple processors
-present, this assumption is not always true.
-When this assumption becomes invalid (that is, we observe significant
-contention for the subsystem mutexes), we can switch over to a finer-grained
-concurrency model for the mutexes.
-Once again, there is a performance trade-off. Fine-grain mutexes
-impose a penalty of approximately 25% (due to the increased number
-of mutexes required for each operation), but allow for higher throughput.
-Using fine-grain mutexes under low contention would cause a decrease
-in performance, so it is important to monitor the system carefully,
-so that the change can be executed only when it will increase system
-throughput without jeopardizing latency.
-
-5. Footprint of an Embedded System
-While traditional systems compete on price-performance, the
-embedded players will compete on price, features, and footprint.
-The earlier sections have focused on features; in this section
-we focus on footprint.
-
-
-
-Object sizes in bytes Subsystem Text Data Bss Btree-specific routines 28812 0 0 Recno-specific routines 7211 0 0 Hash-specific routines 23742 0 0 Memory Pool 14535 0 0 Access method common code 23252 0 0 OS compatibility library 4980 52 0 Support utilities 6165 0 0 All modules for Btree access method only 77744 52 0 All modules for Recno access method only 84955 52 0 All modules for Hash access method only 72674 52 0 All Access Methods 108697 52 0 Locking 12533 0 0 Recovery 26948 8 4 Logging 37367 0 0 Full Package 185545 60 4 6. Related Work
-
-Every three to five years, leading researchers in the database
-community convene to identify future directions in database
-research.
-They produce a report of this meeting, named for the year and
-location of the meeting.
-The most recent of these reports, the 1998 Asilomar report,
-identifies the embedded database market as one of the
-high growth areas in database research [1].
-Not surprisingly, market analysts identify the embedded database
-market as a high-growth area in the commercial sector as well
-[5].
-7. Conclusions
-The coming wave of embedded systems poses a new set of challenges
-for data management.
-The traditional server-based, big footprint systems designed for
-high performance on big iron are not the right approach in this
-environment.
-Instead, application developers need small, fast, versatile systems
-that can be tailored to a specific environment.
-In this paper, we have identified several of the key issues in
-providing these systems and shown how Berkeley DB provides
-many of the characteristics necessary for such applications.
-
-8. References
-
-
- Additional references
-Technical Papers on Berkeley DB
-
-
-Background on Berkeley DB Features
-
-
-Database Systems Theory
-
-
-
-
-Witold Litwin
-Witold is a hell of a guy to take you on a late-night high-speed car
-chase up the mountains of Austria in search of very green wine.
-
-
- Client program
-
-
-
-
-
-
-
-
- Introduction
-
-
-
-
-
-
-
-
- Server program
-
-
-
-
- Using Berkeley DB with Sendmail
-
-APPENDDEF(`confINCDIRS', `-I/usr/local/BerkeleyDB/include')
-APPENDDEF(`confLIBDIRS', `-L/usr/local/BerkeleyDB/lib')
-
-
-
- Closing a database
-
-
-
-#include <sys/types.h>
-#include <stdio.h>
-#include <db.h>
-
-
-
-
- Removing elements from a database
-
-
-
-#include <sys/types.h>
-#include <stdio.h>
-#include <db.h>
-
-
-
-
- Error returns
-
-
-
-
- Retrieving elements from a database
-
-
-
-#include <sys/types.h>
-#include <stdio.h>
-#include <db.h>
-
-
-
-
-
-
- Handles
-
-
-
-
- Introduction
-
-
-
-
- Key/data pairs
-
-
-Key: Data: fruit apple sport cricket drink water
-
-
-
- Opening a database
-
-
-
-
-
-#include <sys/types.h>
-#include <stdio.h>
-#include <db.h>
-
-access.db: Operation not permitted
-
-
-
- Adding elements to a database
-
-
-
-#include <sys/types.h>
-#include <stdio.h>
-#include <db.h>
-
-if ((ret =
- dbp->put(dbp, NULL, &key, &data, DB_NOOVERWRITE)) == 0)
- printf("db: %s: key stored.\n", (char *)key.data);
-else {
- dbp->err(dbp, ret, "DB->put");
- goto err;
-}
-DB->put: DB_KEYEXIST: Key/data pair already exists
-switch (ret =
- dbp->put(dbp, NULL, &key, &data, DB_NOOVERWRITE)) {
-case 0:
- printf("db: %s: key stored.\n", (char *)key.data);
- break;
-case DB_KEYEXIST:
- printf("db: %s: key previously stored.\n",
- (char *)key.data);
- break;
-default:
- dbp->err(dbp, ret, "DB->put");
- goto err;
-}
-
-
-
- Tcl error handling
-
-% berkdb open -create -btree a.db
-db0
-% db0 put dog cat
-0
-% set ret [db0 put -nooverwrite dog newcat]
-DB_KEYEXIST: Key/data pair already exists
-% if { [string first DB_KEYEXIST $ret] != -1 } {
- puts "This was an error; the key existed"
-}
-This was an error; the key existed
-% db0 close
-0
-% exit
-DB_NOTFOUND: No matching key/data pair found
-DB_KEYEMPTY: Non-existent key/data pair
-DB_KEYEXIST: Key/data pair already exists
-
-
-
- Frequently Asked Questions
-
-
-
-
-
-
-
-
-
- Loading Berkeley DB with Tcl
-Installing as a Tcl Package
-
-
-
-# tclsh8.1
-% lappend auto_path /usr/local/BerkeleyDB/lib
-% pkg_mkIndex /usr/local/BerkeleyDB/lib libdb_tcl-3.2.so libdb-3.2.so
Loading Berkeley DB with Tcl
-
-load /usr/local/BerkeleyDB/lib/libdb_tcl-3.2.so
-lappend auto_path "/usr/local/BerkeleyDB/lib"
-package require Db_tcl
-berkdb version -string
-
-
-
- Tcl API programming notes
-
-
-
-
- Using Berkeley DB with Tcl
-
-command_handle operation options
-# First open the database and get a database command handle
-% berkdb open my_data.db
-db0
-#Get some data from that database
-% db0 get my_key
-{{my_key my_data0}{my_key my_data1}}
-#Open a cursor in this database, get a new cursor handle
-% db0 cursor
-db0.c0
-#Get the first data from the cursor
-% db0.c0 get -first
-{{first_key first_data}}
-
-
-
- Test suite FAQ
-
-
-
-
-
-
- Running the test suite
-
-% run_all
-% r archive
-% r btree
-% r env
-% r frecno
-% r hash
-% r join
-% r join
-% r lock
-% r log
-% r mpool
-% r mutex
-% r queue
-% r rbtree
-% r recno
-% r rrecno
-% r subdb
-% r txn
-% test001 btree
-% test001 btree 10
-set testdir ./TESTDIR
-set testdir /var/tmp/db.test
-
-Reference Guide Table of Contents
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Environment infrastructure
-
-
-
-
-
-
- Application structure
-
-
-
-
-
-
-
-
- Database and log file archival
-
-
-
-
-
-
-void
-log_archlist(DB_ENV *dbenv)
-{
- int ret;
- char **begin, **list;
-
-
-
-
- Checkpoints
-
-int
-main(int argc, char *argv)
-{
- extern char *optarg;
- extern int optind;
- DB *db_cats, *db_color, *db_fruit;
- DB_ENV *dbenv;
- pthread_t ptid;
- int ch;
-
-
-
-
- Transactional cursors
-
-int
-main(int argc, char *argv)
-{
- extern char *optarg;
- extern int optind;
- DB *db_cats, *db_color, *db_fruit;
- DB_ENV *dbenv;
- pthread_t ptid;
- int ch;
-
-
-
-
- Opening the databases
-
-int
-main(int argc, char *argv)
-{
- extern char *optarg;
- extern int optind;
- DB *db_cats, *db_color, *db_fruit;
- DB_ENV *dbenv;
- pthread_t ptid;
- int ch;
-
-prompt> db_stat -h TXNAPP -d color
-53162 Btree magic number.
-8 Btree version number.
-Flags:
-2 Minimum keys per-page.
-8192 Underlying database page size.
-1 Number of levels in the tree.
-0 Number of unique keys in the tree.
-0 Number of data items in the tree.
-0 Number of tree internal pages.
-0 Number of bytes free in tree internal pages (0% ff).
-1 Number of tree leaf pages.
-8166 Number of bytes free in tree leaf pages (0.% ff).
-0 Number of tree duplicate pages.
-0 Number of bytes free in tree duplicate pages (0% ff).
-0 Number of tree overflow pages.
-0 Number of bytes free in tree overflow pages (0% ff).
-0 Number of pages on the free list.
-
-
-
- Deadlock detection
-
-void
-env_open(DB_ENV **dbenvp)
-{
- DB_ENV *dbenv;
- int ret;
-
-
-
-
- Opening the environment
-
-#include <sys/types.h>
-#include <sys/stat.h>
-
-prompt> db_stat -e -h TXNAPP
-3.2.1 Environment version.
-120897 Magic number.
-0 Panic value.
-1 References.
-6 Locks granted without waiting.
-0 Locks granted after waiting.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-Mpool Region: 4.
-264KB Size (270336 bytes).
--1 Segment ID.
-1 Locks granted without waiting.
-0 Locks granted after waiting.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-Log Region: 3.
-96KB Size (98304 bytes).
--1 Segment ID.
-3 Locks granted without waiting.
-0 Locks granted after waiting.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-Lock Region: 2.
-240KB Size (245760 bytes).
--1 Segment ID.
-1 Locks granted without waiting.
-0 Locks granted after waiting.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-Txn Region: 5.
-8KB Size (8192 bytes).
--1 Segment ID.
-1 Locks granted without waiting.
-0 Locks granted after waiting.
-
-
-
- Recovery and filesystem operations
-
-
-
-
-
-
- Atomicity
-
-thread #1 read record: the value is 2
-thread #2 read record: the value is 2
-thread #2 write record + 5 back into the database (new value 7)
-thread #1 write record + 3 back into the database (new value 5)
-int
-main(int argc, char *argv)
-{
- extern char *optarg;
- extern int optind;
- DB *db_cats, *db_color, *db_fruit;
- DB_ENV *dbenv;
- pthread_t ptid;
- int ch;
-
-
-
-
- Building transaction protected applications
-
-
-
-
- Log file removal
-
-
-
-
-
-int
-main(int argc, char *argv)
-{
- ...
-
-
-
-
- Recoverability and deadlock avoidance
-
-int
-main(int argc, char *argv)
-{
- extern char *optarg;
- extern int optind;
- DB *db_cats, *db_color, *db_fruit;
- DB_ENV *dbenv;
- pthread_t ptid;
- int ch;
-
-
-
-
- Repeatable reads
-
-
-
-
- Berkeley DB recoverability
-
-
-
-
-
-
- Recovery procedures
-
-
-
-
-
-
-
-
-
-
- Terminology
-
-
-
-
-
-
- Transaction throughput
-
-
-
-
-
-
-
-
-
-% testfile -b256 -o1000
-running: 1000 ops
-Elapsed time: 16.641934 seconds
-1000 ops: 60.09 ops per second
-
-
-
- Why transactions?
-
-
-
-
-
-
- Configuring transactions
-
-
-
-
- Berkeley DB and transactions
-
-
-
-
- Transaction limits
-Transaction IDs
-
-2^31 / (600 * 15 * 60 * 60) = 66
Cursors
-Multiple Threads of Control
-
-
-
-
- Nested transactions
-
-
-
-
- Transactions and non-Berkeley DB applications
-
-
-
-
- Release 2.0: converting applications
-
-
-
-
-
-
- Release 2.0: upgrade requirements
-
-
-
-
- Release 2.0: introduction
-
-
-
-
- Release 2.0: system integration
-
-
-
-
-Upgrading Berkeley DB 1.XX applications to Berkeley DB 2.0
-
-
-
-
- Release 3.0: DB->sync and DB->close
-
-
-
-
- Release 3.0: additional C++ changes
-
-int dberr;
-DbEnv *dbenv = new DbEnv(DB_CXX_NO_EXCEPTIONS);
-
-
-
- Release 3.0: the DB structure
-
-DB *db;
-DB_TYPE type;
-
-DB *db;
-DB_TYPE type;
-
-
-DB field Berkeley DB 3.X method byteswapped DB->get_byteswapped db_errcall DB->set_errcall db_errfile DB->set_errfile db_errpfx DB->set_errpfx db_paniccall DB->set_paniccall type DB->get_type
-
-
-
- Release 3.0: the Db class for C++ and Java
-
-// Note: by default, errors are thrown as exceptions
-Db *table;
-Db::open("lookup.db", DB_BTREE, DB_CREATE, 0644, dbenv, 0, &table);
-// Note: by default, errors are thrown as exceptions
-Db *table = new Db(dbenv, 0);
-table->open("lookup.db", NULL, DB_BTREE, DB_CREATE, 0644);
-// Note: errors are thrown as exceptions
-Db table = Db.open("lookup.db", Db.DB_BTREE, Db.DB_CREATE, 0644, dbenv, 0);
-// Note: errors are thrown as exceptions
-Db table = new Db(dbenv, 0);
-table.open("lookup.db", null, Db.DB_BTREE, Db.DB_CREATE, 0644);
-
-
-
- Release 3.0: the DB_ENV structure
-
-DB_ENV *dbenv;
-
-DB_ENV *dbenv;
-
-
-DB_ENV field Berkeley DB 3.X method db_errcall DBENV->set_errcall db_errfile DBENV->set_errfile db_errpfx DBENV->set_errpfx db_lorder This field was removed from the DB_ENV structure in the Berkeley DB
-3.0 release as no application should have ever used it. Any code using
-it should be evaluated for potential bugs. db_paniccall DBENV->set_paniccall db_verbose DBENV->set_verbose
- lg_max DBENV->set_lg_max lk_conflicts DBENV->set_lk_conflicts lk_detect DBENV->set_lk_detect lk_max DBENV->set_lk_max lk_modes DBENV->set_lk_conflicts mp_mmapsize DBENV->set_mp_mmapsize mp_size DBENV->set_cachesize
- tx_info This field was used by applications as an argument to the transaction
-subsystem functions. As those functions take references to a
-DB_ENV structure as arguments in the Berkeley DB 3.0 release, it should
-no longer be used by any application. tx_max DBENV->set_tx_max tx_recover DBENV->set_tx_recover
-
-
-
- Release 3.0: the DbEnv class for C++ and Java
-
-int dberr;
-DbEnv *dbenv = new DbEnv();
-
-int dberr;
-DbEnv *dbenv = new DbEnv(0);
-
-int dberr;
-DbEnv dbenv = new DbEnv();
-
-int dberr;
-DbEnv dbenv = new DbEnv(0);
-
-
-
-
- Release 3.0: the DBINFO structure
-
-DB_INFO dbinfo;
-
-DB *db;
-int ret;
-
-
-DB_INFO field Berkeley DB 3.X method bt_compare DB->set_bt_compare bt_minkey DB->set_bt_minkey bt_prefix DB->set_bt_prefix db_cachesize DB->set_cachesize
- db_lorder DB->set_lorder db_malloc DB->set_malloc db_pagesize DB->set_pagesize dup_compare DB->set_dup_compare flags DB->set_flags
- h_ffactor DB->set_h_ffactor h_hash DB->set_h_hash h_nelem DB->set_h_nelem re_delim DB->set_re_delim re_len DB->set_re_len re_pad DB->set_re_pad re_source DB->set_re_source
-
-
-
- Release 3.0: upgrade requirements
-
-
-
-
- Release 3.0: EACCES
-
-
-
-
- Release 3.0: EAGAIN
-
-
-
-
- Release 3.0: environment open/close/unlink
-
-db_appinit, db_appexit
-lock_open, lock_close, lock_unlink
-log_open, log_close, log_unlink
-memp_open, memp_close, memp_unlink
-txn_open, txn_close, txn_unlink
-db_env_create, DBENV->open, DBENV->close,
-DBENV->remove
-/*
- * db_init --
- * Initialize the environment.
- */
-DB_ENV *
-db_init(home)
- char *home;
-{
- DB_ENV *dbenv;
-
-/*
- * db_init --
- * Initialize the environment.
- */
-int
-db_init(home, dbenvp)
- char *home;
- DB_ENV **dbenvp;
-{
- int ret;
- DB_ENV *dbenv;
-
-lock_open(dir, DB_CREATE, 0664, dbenv, ®ionp);
-if ((ret = db_env_create(&dbenv, 0)) != 0)
- return (ret);
-
-DB_ENV *dbenv;
-
-DB_ENV *dbenv;
-
-
-
-
- Release 3.0: function arguments
-
-lock_detect
-lock_get
-lock_id
-lock_put
-lock_stat
-lock_vec
-DB_LOCKTAB *lt;
-DB_LOCK lock;
- ret = lock_put(lt, lock);
-DB_ENV *dbenv;
-DB_LOCK *lock;
- ret = lock_put(dbenv, lock);
-log_archive
-log_compare
-log_file
-log_flush
-log_get
-log_put
-log_register
-log_stat
-log_unregister
-memp_fopen
-memp_register
-memp_stat
-memp_sync
-memp_trickle
-
-
-
- Release 3.0: introduction
-
-
-
-
- Release 3.0: additional Java changes
-
-
-
-
- Release 3.0: DB->join
-
-
-
-
- Release 3.0: db_jump_set
-
-
-db_jump_set argument Berkeley DB 3.X method DB_FUNC_CLOSE db_env_set_func_close DB_FUNC_DIRFREE db_env_set_func_dirfree DB_FUNC_DIRLIST db_env_set_func_dirlist DB_FUNC_EXISTS db_env_set_func_exists DB_FUNC_FREE db_env_set_func_free DB_FUNC_FSYNC db_env_set_func_fsync DB_FUNC_IOINFO db_env_set_func_ioinfo DB_FUNC_MALLOC db_env_set_func_malloc DB_FUNC_MAP db_env_set_func_map DB_FUNC_OPEN db_env_set_func_open DB_FUNC_READ db_env_set_func_read DB_FUNC_REALLOC db_env_set_func_realloc DB_FUNC_RUNLINK The DB_FUNC_RUNLINK functionality has been removed from the Berkeley DB
-3.0 release, and should be removed from the application. DB_FUNC_SEEK db_env_set_func_seek DB_FUNC_SLEEP db_env_set_func_sleep DB_FUNC_UNLINK db_env_set_func_unlink DB_FUNC_UNMAP db_env_set_func_unmap DB_FUNC_WRITE db_env_set_func_write DB_FUNC_YIELD db_env_set_func_yield
-
-
-
- Release 3.0: lock_detect
-
-
-
-
- Release 3.0: DB_LOCK_NOTHELD
-
-
-
-
- Release 3.0: lock_put
-
-
-
-
- Release 3.0: lock_stat
-
-
-
-
- Release 3.0: log_register
-
-
-
-
- Release 3.0: log_stat
-
-
-
-
- Release 3.0: memp_stat
-
-
-
-
- Release 3.0: database open/close
-
-DB *dbp;
-DB_ENV *dbenv;
-int ret;
-
-DB *dbp;
-DB_ENV *dbenv;
-int ret;
-
-
-
-
- Release 3.0: DB_RMW
-
-
-
-
- Release 3.0: DB->stat
-
-
-Upgrading Berkeley DB 2.X.X applications to Berkeley DB 3.0
-
-
-
-
- Release 3.0: txn_begin
-
-
-
-
- Release 3.0: txn_commit
-
-
-
-
- Release 3.0: txn_stat
-
-
-
-
- Release 3.0: db_value_set
-
-
-db_value_set argument Berkeley DB 3.X method DB_MUTEX_LOCKS DBENV->set_mutexlocks DB_REGION_ANON The DB_REGION_ANON functionality has
-been replaced by the DB_SYSTEM_MEM and DB_PRIVATE flags
-to the DBENV->open function. A direct translation is not
-available, please review the DBENV->open manual page for more
-information. DB_REGION_INIT db_env_set_region_init DB_REGION_NAME The DB_REGION_NAME functionality has
-been replaced by the DB_SYSTEM_MEM and DB_PRIVATE flags
-to the DBENV->open function. A direct translation is not
-available, please review the DBENV->open manual page for more
-information. DB_TSL_SPINS db_env_set_tas_spins
-
-
-
- Release 3.0: db_xa_open
-
-
-
-
- Release 3.1: DB->stat
-
-
-
-
- Release 3.1: DBENV->open, DBENV->remove
-
-
-Previous config string Berkeley DB 3.1 version method DB_DATA_DIR DBENV->set_data_dir DB_LOG_DIR DBENV->set_lg_dir DB_TMP_DIR DBENV->set_tmp_dir
-
-
-
- Release 3.1: upgrade requirements
-
-
-
-
- Release 3.1: identical duplicate data items
-
-
-
-
- Release 3.1: environment configuration
-
-
-DB_ENV method Berkeley DB 3.1 function DBENV->set_func_close db_env_set_func_close DBENV->set_func_dirfree db_env_set_func_dirfree DBENV->set_func_dirlist db_env_set_func_dirlist DBENV->set_func_exists db_env_set_func_exists DBENV->set_func_free db_env_set_func_free DBENV->set_func_fsync db_env_set_func_fsync DBENV->set_func_ioinfo db_env_set_func_ioinfo DBENV->set_func_malloc db_env_set_func_malloc DBENV->set_func_map db_env_set_func_map DBENV->set_func_open db_env_set_func_open DBENV->set_func_read db_env_set_func_read DBENV->set_func_realloc db_env_set_func_realloc DBENV->set_func_rename db_env_set_func_rename DBENV->set_func_seek db_env_set_func_seek DBENV->set_func_sleep db_env_set_func_sleep DBENV->set_func_unlink db_env_set_func_unlink DBENV->set_func_unmap db_env_set_func_unmap DBENV->set_func_write db_env_set_func_write DBENV->set_func_yield db_env_set_func_yield DBENV->set_pageyield db_env_set_pageyield DBENV->set_region_init db_env_set_region_init DBENV->set_mutexlocks DBENV->set_mutexlocks DBENV->set_tas_spins db_env_set_tas_spins
-
-
-
- Release 3.1: introduction
-
-
-
-
- Release 3.1: log_register
-
-
-
-
- Release 3.1: log file pre-allocation
-
-
-
-
- Release 3.1: memp_register
-
-
-
-
- Release 3.1: DB->put
-
-DBT key;
-db_recno_t recno;
-
-DBT key;
-db_recno_t recno;
-
-DBT key;
-db_recno_t recno;
-
-
-
-
- Release 3.1: DBENV->set_feedback, DB->set_feedback
-
-
-
-
- Release 3.1: DBENV->set_paniccall, DB->set_paniccall
-
-
-
-
- Release 3.1: DBENV->set_tx_recover
-
-
-Previous flag Berkeley DB 3.1 version flag TXN_BACKWARD_ROLL DB_TXN_BACKWARD_ROLL TXN_FORWARD_ROLL DB_TXN_FORWARD_ROLL TXN_OPENFILES DB_TXN_OPENFILES TXN_REDO DB_TXN_FORWARD_ROLL TXN_UNDO DB_TXN_ABORT
-
-
-
- Release 3.1: DB_SYSTEM_MEM
-
-
-
-
- Release 3.1: Tcl API
-
-
-
-
- Release 3.1: DB_TMP_DIR
-
-
-Upgrading Berkeley DB 3.0.X applications to Berkeley DB 3.1
-
-
-
-
- Release 3.1: txn_checkpoint
-
-
-
-
- Release 3.2: DB callback functions, app_private field
-
-
-
-
- Release 3.2: db_dump
-
-
-
-
- Release 3.2: upgrade requirements
-
-
-
-
- Release 3.2: Java and C++ object re-use
-
-
-
-
- Release 3.2: DB_INCOMPLETE
-
-
-
-
- Release 3.2: introduction
-
-
-
-
- Release 3.2: DBENV->set_mutexlocks
-
-
-
-
- Release 3.2: Java java.io.FileNotFoundException
-
-
-
-
- Release 3.2: Logically renumbering records
-
-
-
-
- Release 3.2: DBENV->set_flags
-
-
-Upgrading Berkeley DB 3.1.X applications to Berkeley DB 3.2
-
-
-
-
- Release 3.2: DBENV->set_tx_recover
-
-
-
-
- Upgrading Berkeley DB installations
-
-
-
-
-
-
-
-
-
-
-
-
- Configuring Berkeley DB with the Tuxedo System
-
-In that case, the resource manager file will be located in:
-/home/tuxedo
-Edit the resource manager file, adding the following line:
-/home/tuxedo/udataobj/RM
-BERKELEY-DB:db_xa_switch:-L${DB_INSTALL}/lib -ldb \
- -lsocket -ldl -lm
-buildtms -v -o DBRM -r BERKELEY-DB
-rm_name:dir
-group_tm LMID=myname GRPNO=1 TMSNAME=DBRM TMSCOUNT=2 \
- OPENINFO="BERKELEY-DB:/home/dbhome"
-DB_DATA_DIR /home/datafiles
-DB_LOG_DIR /home/log
-
-
-
-
- Frequently Asked Questions
-
-
-
-
-
-
-
-
-
-
- Introduction
-
-__db_xa_close Close the resource manager.
-__db_xa_commit Commit the specified transaction.
-__db_xa_complete Wait for asynchronous operations to
- complete.
-__db_xa_end Disassociate the application from a
- transaction.
-__db_xa_forget Forget about a transaction that was heuristically
- completed. (Berkeley DB does not support heuristic
- completion.)
-__db_xa_open Open the resource manager.
-__db_xa_prepare Prepare the specified transaction.
-__db_xa_recover Return a list of prepared, but not yet
- committed transactions.
-__db_xa_rollback Abort the specified transaction.
-__db_xa_start Associate the application with a
- transaction.
-
-
-Building Client/Server Applications Using Tuxedo,
-by Hall, John Wiley & Sons, Inc. Publishers.
-X/Open CAE Specification
-Distributed Transaction Processing: The XA Specification,
-X/Open Document Number: XO/CAE/91/300.
-The Tuxedo System,
-by Andrade, Carges, Dwyer and Felts, Addison Wesley Longman Publishers.
-
-
-
-
-
-
-
-
diff --git a/bdb/docs/sleepycat/legal.html b/bdb/docs/sleepycat/legal.html
deleted file mode 100644
index 1945b3976d0..00000000000
--- a/bdb/docs/sleepycat/legal.html
+++ /dev/null
@@ -1,56 +0,0 @@
-
-
-
-
-
-
-
-
-
-General:
-
-
-db@sleepycat.com
-
-
-
-
-
-
-
-Sales and Marketing:
-
-
-sales@sleepycat.com
-
-
-+1-510-526-3972
-+1-877-SLEEPYCAT (USA only, toll-free)
-
-
-
-
-
-Technical Support:
-
-
-support@sleepycat.com
-
-
-
-
-
-
-
-Web Site:
-
-
-webmaster@sleepycat.com
-
-
-
-
-
-
-
-Press Inquiries:
-
-
-Michael Olson, VP Marketing
-
-
-Sleepycat Software, Inc.
-mao@sleepycat.com
-
-
-
-
-
-Postal Mail:
-
-
-Massachussetts Corporate Office
-
-
-
-Sleepycat Software Inc.
-394 E. Riding Dr.
-Carlisle, MA 01741-1601
-
-
-
-
-
-West Coast Sales Office
-
-
-Sleepycat Software Inc.
-1509 McGee St.
-Berkeley CA 94703
-Sleepycat Software Legal Notices
-Sleepycat Software Product License
-
-/*
- * Copyright (c) 1990-2000
- * Sleepycat Software. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * 3. Redistributions in any form must be accompanied by information on
- * how to obtain complete source code for the DB software and any
- * accompanying software that uses the DB software. The source code
- * must either be included in the distribution or be available for no
- * more than the cost of distribution plus a nominal fee, and must be
- * freely redistributable under reasonable conditions. For an
- * executable file, complete source code means the source code for all
- * modules it contains. It does not include source code for modules or
- * files that typically accompany the major components of the operating
- * system on which the executable file runs.
- *
- * THIS SOFTWARE IS PROVIDED BY SLEEPYCAT SOFTWARE ``AS IS'' AND ANY EXPRESS
- * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- * WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
- * NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL SLEEPYCAT SOFTWARE
- * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
- * THE POSSIBILITY OF SUCH DAMAGE.
- */
-/*
- * Copyright (c) 1990, 1993, 1994, 1995
- * The Regents of the University of California. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * 3. Neither the name of the University nor the names of its contributors
- * may be used to endorse or promote products derived from this software
- * without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-/*
- * Copyright (c) 1995, 1996
- * The President and Fellows of Harvard University. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * 3. Neither the name of the University nor the names of its contributors
- * may be used to endorse or promote products derived from this software
- * without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY HARVARD AND ITS CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL HARVARD OR ITS CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-
-
-berkeley_db_svc
-
-
-
-
-
-berkeley_db_svc [-Vv] [-h home]
- [-I seconds] [-L file] [-t seconds] [-T seconds]
Description
-
-
-
-
-This file will be removed if the berkeley_db_svc utility exits gracefully.
-berkeley_db_svc: ### Wed Jun 15 01:23:45 EDT 1995
Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_archive
-
-
-
-
-
-db_archive [-alsVv] [-h home]
Description
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_checkpoint
-
-
-
-
-
-db_checkpoint [-1Vv]
- [-h home] [-k kbytes] [-L file] [-p min]
Description
-
-
-
-
-This file will be removed if the db_checkpoint utility exits gracefully.
-db_checkpoint: ### Wed Jun 15 01:23:45 EDT 1995
Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_deadlock
-
-
-
-
-
-db_deadlock [-Vvw]
- [-a o | y] [-h home] [-L file] [-t sec]
Description
-
-
-
-
-This file will be removed if the db_deadlock utility exits gracefully.
-db_deadlock: ### Wed Jun 15 01:23:45 EDT 1995
Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_dump
-
-
-
-
-
-db_dump [-klNpRrV] [-d ahr]
- [-f output] [-h home] [-s database] file
-db_dump185 [-p] [-f output] file
Description
-
-
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_load
-
-
-
-
-
-db_load [-nTV] [-c name=value] [-f file]
- [-h home] [-t btree | hash | queue | recno] file
Description
-
-
-
-Examples
-
-awk -F: '{print $1; print $0}' < /etc/passwd |
- sed 's/\\/\\\\/g' | db_load -T -t hash passwd.dbEnvironment Variables
-
-
-Supported Keywords
-The following keywords are supported for the -c command-line
-option to the db_load utility. See DB->open for further
-discussion of these keywords and what values should be specified.
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_printlog
-
-
-
-
-
-db_printlog [-NV] [-h home]
Description
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_recover
-
-
-
-
-
-db_recover [-cVv] [-h home] [-t [[CC]YY]MMDDhhmm[.SS]]]
Description
-
-
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_stat
-
-
-
-
-
-db_stat [-celmNtV]
- [-C Acfhlmo] [-d file [-s database]] [-h home] [-M Ahlm]
Description
-
-
-
-
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_upgrade
-
-
-
-
-
-db_upgrade [-NsV] [-h home] file ...
Description
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-
-
-
-
-db_verify
-
-
-
-
-
-db_verify [-NqV] [-h home] file ...
Description
-
-
-
-Environment Variables
-
-
-See Also
-berkeley_db_svc,
-db_archive,
-db_checkpoint,
-db_deadlock,
-db_dump,
-db_load,
-db_recover,
-db_stat,
-db_upgrade,
-and
-db_verify.
-
-Berkeley DB Supporting Utilities
-
-
-Utility Description berkeley_db_svc RPC server utility db_archive Archival utility db_checkpoint Transaction checkpoint utility db_deadlock Deadlock detection utility db_dump Database dump utility db_load Database load utility db_printlog Transaction log display utility db_recover Recovery utility db_stat Statistics utility db_upgrade Database upgrade utility db_verify Verification utility