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 dafd5772a14..00000000000 Binary files a/bdb/docs/images/api.gif and /dev/null differ diff --git a/bdb/docs/images/next.gif b/bdb/docs/images/next.gif deleted file mode 100644 index 667ee061a9f..00000000000 Binary files a/bdb/docs/images/next.gif and /dev/null differ diff --git a/bdb/docs/images/prev.gif b/bdb/docs/images/prev.gif deleted file mode 100644 index 11dfc5256ee..00000000000 Binary files a/bdb/docs/images/prev.gif and /dev/null differ diff --git a/bdb/docs/images/ps.gif b/bdb/docs/images/ps.gif deleted file mode 100644 index 0f565bc1db7..00000000000 Binary files a/bdb/docs/images/ps.gif and /dev/null differ diff --git a/bdb/docs/images/ref.gif b/bdb/docs/images/ref.gif deleted file mode 100644 index 75be9c1f348..00000000000 Binary files a/bdb/docs/images/ref.gif and /dev/null differ diff --git a/bdb/docs/images/sleepycat.gif b/bdb/docs/images/sleepycat.gif deleted file mode 100644 index 5e768f74f2b..00000000000 Binary files a/bdb/docs/images/sleepycat.gif and /dev/null differ diff --git a/bdb/docs/index.html b/bdb/docs/index.html deleted file mode 100644 index ad638e776c9..00000000000 --- a/bdb/docs/index.html +++ /dev/null @@ -1,75 +0,0 @@ - - -
-
-
-
-... the embedded database companytm - -
-
-
-
| Interface Documentation | -Building Berkeley DB | -
|---|---|
|
- C API - C API Index -
- C++ API
- Java API
- Tcl API |
- Building for UNIX and QNX systems -
- Building for Win32 platforms |
-
-
| Additional Documentation | -Company and Product Information | -
|
- Supporting Utilities - |
- Contacting Sleepycat Software - Commercial Product List - License - Release Patches and Change Logs - Sleepycat Software Home Page - |
-
-
-
-
-
|
-  
- |
-
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: -
int ret;
-if ((ret = dbp->put(dbp, NULL, &key, &data, 0)) != 0) {
- fprintf(stderr, "put failed: %s\n", db_strerror(ret));
- return (1);
-}
-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. -
#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);
-}
-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: -
-my_app: access.db: Permission denied. -my_app: contact your system administrator: session ID was 14
|
- |
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: -
-Primary key: Primary data: -apple Convenience Store -blueberry Farmer's Market -peach Shopway -pear Farmer's Market -raspberry Shopway -strawberry Farmer's Market
We would then create a secondary index with the key color, and, -as the data items, the names of fruits of different colors. -
-Secondary key: Secondary data: -blue blueberry -red apple -red raspberry -red strawberry -yellow peach -yellow pear
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: -
-Secondary key: Secondary data: -expensive blueberry -expensive peach -expensive pear -expensive strawberry -inexpensive apple -inexpensive pear -inexpensive raspberry
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: -
-Return the personnel records of all people named smith with the job -title manager.
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. -
-DBC *name_curs, *job_curs, *join_curs; -DBC *carray[3]; -DBT key, data; -int ret, tret; --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 -
-size = 20 -doff = 0 -dlen = 20 -data = abcdefghijabcdefghij --Result: The 20 bytes at offset 0 are replaced by the 20 bytes of data, -i.e., the entire record is replaced. -
-ABCDEFGHIJ0123456789 -> abcdefghijabcdefghij -
-size = 10 -doff = 20 -dlen = 0 -data = abcdefghij --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 -
-size = 10 -doff = 10 -dlen = 5 -data = abcdefghij --Result: The 5 bytes at offset 10 are replaced by the 10 bytes of data. -
-ABCDEFGHIJ0123456789 -> ABCDEFGHIJabcdefghij56789 -
-size = 10 -doff = 10 -dlen = 0 -data = abcdefghij --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 -
-size = 10 -doff = 2 -dlen = 15 -data = abcdefghij --Result: The 15 bytes at offset 2 are replaced by the 10 bytes of data. -
-ABCDEFGHIJ0123456789 -> ABabcdefghij789 -
-size = 10 -doff = 0 -dlen = 0 -data = abcdefghij --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 -
-size = 0 -doff = 0 -dlen = 10 -data = "" --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 -
-size = 10 -doff = 25 -dlen = 0 -data = abcdefghij --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: -
int
-compare_int(dbp, a, b)
- DB *dbp;
- const DBT *a, *b;
-{
- int ai, bi;
-
- /*
- * 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: -
int
-compare_dbt(dbp, a, b)
- DB *dbp;
- const DBT *a, *b;
-{
- u_char *p1, *p2;
-
- /*
- * 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.) -
-maximum_size = page_size / (minimum_keys * 2)
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: -
u_int32_t
-compare_prefix(dbp, a, b)
- DB *dbp;
- const DBT *a, *b;
-{
- size_t cnt, len;
- u_int8_t *p1, *p2;
-
- 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: -
-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. -
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: -
-(pagesize - 32) / (average_key_size + average_data_size + 8)
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: -
-#include <db.h>
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: -
-#include <db_cxx.h>
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 48c52aed5a2..00000000000 Binary files a/bdb/docs/ref/arch/bigpic.gif and /dev/null differ diff --git a/bdb/docs/ref/arch/bigpic.html b/bdb/docs/ref/arch/bigpic.html deleted file mode 100644 index 6c945744e83..00000000000 --- a/bdb/docs/ref/arch/bigpic.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - -
-
|
-
- |
-
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: -
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);
-}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: -
retry: if ((ret = txn_begin(dbenv, NULL, &tid)) != 0) {
- dbenv->err(dbenv, ret, "txn_begin");
- exit (1);
- }
-
- 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 5eb7ae8da58..00000000000 Binary files a/bdb/docs/ref/arch/smallpic.gif and /dev/null differ diff --git a/bdb/docs/ref/arch/utilities.html b/bdb/docs/ref/arch/utilities.html deleted file mode 100644 index 72bfe52b21c..00000000000 --- a/bdb/docs/ref/arch/utilities.html +++ /dev/null @@ -1,62 +0,0 @@ - - - - -
-
|
-
- |
-
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. -
-xlc_r ... -cc -D_THREAD_SAFE -lc_r ...
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: -
-#ifdef HAVE_FILE_OFFSET_BITS -#define _LARGE_FILES /* AIX specific. */ -#endif
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: -
-prompt: env CC=gcc ../dist/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: -
-prompt: env CFLAGS=-O2 ../dist/configure
To specify header file search directories and other miscellaneous options -for the C preprocessor and compiler, use the CPPFLAGS environment variable: -
-prompt: env CPPFLAGS=-I/usr/contrib/include ../dist/configure
To specify debugging and optimization options for the C++ compiler, -use the CXXFLAGS environment variable: -
-prompt: env CXXFLAGS=-Woverloaded-virtual ../dist/configure
To specify miscellaneous options or additional library directories for -the linker, use the LDFLAGS environment variable: -
-prompt: env LDFLAGS="-N32 -L/usr/local/lib" ../dist/configure
If you want to specify additional libraries, set the LIBS environment -variable before running configure. For example: -
-prompt: env LIBS="-lposix -lsocket" ../dist/configure
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: -
-prompt: LIBS="-lposix -lsocket" ../dist/configure
and in csh or tcsh, you could do: -
-prompt: setenv LIBS "-lposix -lsocket" -prompt: ../dist/configure
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: -
-cc -D_THREAD_SAFE -pthread ...
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: -
-*** /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); -
|
- |
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: -
-cc -D_REENTRANT ...
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. -
-#error "Large Files (ILP32) not supported in strict ANSI mode."
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 -
-chatr +s enable -l /full/path/to/libdb-3.2.sl ...
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: -
| 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) |
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: -
-prompt: ../dist/configure --bindir=/usr/local/bin
Any of these values, including docdir, may be changed when doing -the install itself: -
-prompt: make prefix=/usr/contrib/bdb install
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: -
-../dist/configure -make
This will build the Berkeley DB library. -
To install the Berkeley DB library, enter: -
-make install
To rebuild Berkeley DB, enter: -
-make clean -make
If you change your mind about how Berkeley DB is to be configured, you must start -from scratch by entering: -
-make realclean -../dist/configure -make
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: -
-mkdir build_bsdos3.0 -cd build_bsdos3.0 -../dist/configure -make
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: -
-cc -D_SGI_MP_SOURCE ...
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: -
-cc -D_REENTRANT ...
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 @@ - - - - -
-
|
-
- |
-
-symbol __muldi3: referenced symbol not found -symbol __cmpdi2: referenced symbol not found
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: -
-cc ... -lpthread ... -cc ... -lthread ... -xlc_r ... -cc ... -mt ...
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: -
-cc -o db_dump185 db_dump185.o -ld: -Unresolved: -dbopen
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: -
-DB185INC= -DB185LIB=
So that the system Berkeley DB 1.85 header file and library are found, e.g., -
-DB185INC=/usr/local/include -DB185LIB=-ldb185
|
- |
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: -
-cc -D_REENTRANT ...
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: -
-cc -L BUILD_DIRECTORY/.libs -o testprog testprog.o -ldb-3.5 -env LD_LIBRARY_PATH="BUILD_DIRECTORY/.libs:$LD_LIBRARY_PATH" ./testprog
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, -
-libtool gdb db_dump
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: -
-libtool --mode=execute my_debugger db_dump
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: -
-cc -mt ... -cc -D_REENTRANT ... -lthread -cc -D_REENTRANT ... -lpthread
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: -
-% which cc -/usr/ucb/cc -% cc -/usr/ucb/cc: language optional software package not installed
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: -
-checking whether the C compiler (cc -O ) works... no -configure: error: installation or configuration problem: C compiler cannot create executables.
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.: -
-env CC=gcc ../dist/configure
and reconfigure. -
If you are using the --configure-cxx option, you may also want to specify -a C++ compiler, e.g.: -
-env CC=gcc CCC=g++ ../dist/configure
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. -
-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).
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: -
-set tclsh_path ...
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: -
-set test_path ...
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: -
-% source ../test/test.tcl
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. -
| File | Description |
|---|---|
| Berkeley DB.wsp | Berkeley DB Workspace file |
| Berkeley DB.wpj | Berkeley DB Project file |
| ex_*/*.wpj | Example programs project files |
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. -
| 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 |
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: -
| 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. |
|
- |
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: -
| 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 -) |
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: -
-java com.sleepycat.examples.AccessExample
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: -
-set tclsh_path SET_YOUR_TCLSH_PATH
You will want to use the location of the tclsh program. For -example, if Tcl is installed as d:/tcl, this line should be: -
-set tclsh_path d:/tcl/bin/tclsh83d.exe
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: -
-[22][28]db_big: rec: 43 txnid 80000963 prevlsn [21][10483281]
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. - -
| 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. |
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: -
-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
If you need a complete list of both committed and aborted transactions, -then the script status.awk will produce that. The syntax is: -
-awk -f status.awk log_output
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: -
-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
The awk script fileid.awk, allows you to extract all log records that -affect particular files. The syntax for the fileid.awk script is: -
-awk -f fileid.awk PGNO=fids log_output
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: -
-awk -f pgno.awk PGNO=pgnolist log_output
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: -
-awk -f range.awk START_FILE=sf START_OFFSET=so END_FILE=ef END_OFFSET=eo log_output
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 @@ - - - - -
-
|
-
- |
-
| 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. |
|
- |
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: -
awk -F: '{print $1; print $0}' < /etc/passwd |\
- sed 's/\\/\\\\/g' | db_load -T -t hash passwd.dbNote 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: -
int ret;
-if ((ret = dbenv->set_cachesize(dbenv, 0, 32 * 1024)) != 0) {
- fprintf(stderr, "set_cachesize failed: %s\n", db_strerror(ret));
- return (1);
-}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: -
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);
-}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: -
-my_app: open: /tmp/home: Permission denied. -my_app: contact your system administrator: session ID was 2
|
- |
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.: -
-env DB_HOME=/database/my_home application
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. -
-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", ...);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: -
-DBENV->set_data_dir(DBENV, "/b/data2"); -DBENV->set_data_dir(DBENV, "data1"); -DBENV->open(DBENV, "/a/database", ...);
|
- |
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: -
-db-VERSION - / \ - java libdb_java - | | - src ... - | - com - | - sleepycat - / \ - db examples - | | - ... ... -
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: -
-db-VERSION\build_win32\Release
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: -
-java.lang.UnsatisfiedLinkError
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: -
-java.lang.NoClassDefFoundError
To ensure that everything is running correctly, you may want to try a -simple test from the example programs in: -
-db-VERSION/java/src/com/sleepycat/examples
For example, the sample program: -
-% java com.sleepycat.examples.AccessExample
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: -
-DBENV->set_lk_max_locks -DBENV->set_lk_max_lockers -DBENV->set_lk_max_objects
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. -
-Notheld Read Write -Notheld 0 0 0 -Read* 0 0 1 -Write** 0 1 1 -
|
- |
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: -
-(10 * 2^20 * 2000000000) / (6000 * 500 * 365 * 60 * 60 * 24) = ~221
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: -
-useful-bytes-per-page = (page-size - page-overhead) * page-fill-factor --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: -
-6941 = (8192 - 26) * .85
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: -
-1560000000 = 60000000 * ((8 * 2) + (5 * 2))
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. -
-224751 = 1560000000 / 6941
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. -
-1841160192 = 224751 * 8192
The formulas for the Hash access method are as follows: -
-useful-bytes-per-page = (page-size - page-overhead) --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: -
-8166 = (8192 - 26)
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: -
-1320000000 = 60000000 * ((16 + 6))
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. -
-161646 = 1320000000 / 8166
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. -
-1324204032 = 161646 * 8192
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. -
-371 = 8166 / 22
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. -
-314 = 8166 / 26
With a fill factor of 314, then the formula for computing database size -is: -
-npages = npairs / pairs-per-page
or 191082. -
-191082 = 60000000 / 314
At 191082 pages, the total database size would be 1565343744 or 1.46GB. -
-1565343744 = 191082 * 8192
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: -
-BEGIN RECORD_NAME RECORD_NUMBER
and ends with the line: -
-END
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: -
-ARG | DBT | POINTER variable_name variable_type printf_format
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: -
-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
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. -
-DBENV->set_mutexlocks -db_env_set_pageyield -db_env_set_panicstate -db_env_set_region_init -db_env_set_tas_spins
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
-
-Keith Bostic
-
-Margo Seltzer
-
-
-Sleepycat Software, Inc.
-
-
-
-
-Abstract
-
-
-- --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. -
| [Come79] | -
- -Comer, D., -"The Ubiquitous B-tree," -ACM Computing Surveys -Volume 11, number 2, -June 1979. - |
-
| -[Gray93] - | -
- -Gray, J., and Reuter, A., -Transaction Processing: Concepts and Techniques, -Morgan-Kaufman Publishers, -1993. - |
-
| -[IEEE96] - | -
- -Institute for Electrical and Electronics Engineers, -IEEE/ANSI Std 1003.1, -1996 Edition. - |
-
| -[Litw80] - | -
- -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. - |
-
| -[Open94] - | -
- -The Open Group, -Distributed TP: The XA+ Specification, Version 2, -The Open Group, 1994. - |
-
| -[Open99] - | -
- -Opensource.org, -"Open Source Definition," -www.opensource.org/osd.html, -version 1.4, -1999. - |
-
| -[Raym98] - | -
- -Raymond, E.S., -"The Cathedral and the Bazaar," - -www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html, -January 1998. - |
-
| -[Selt91] - | -
- -Seltzer, M., and Yigit, O., -"A New Hashing Package for UNIX," -Proceedings 1991 Winter USENIX Conference, -Dallas, TX, -January 1991. - |
-
| -[Selt92] - | -
- -Seltzer, M., and Olson, M., -"LIBTP: Portable Modular Transactions for UNIX," -Proceedings 1992 Winter Usenix Conference -San Francisco, CA, -January 1992.] - |
-
| -[Ston82] - | -
- -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. - -
| 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 |
-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
-
- 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