diff options
Diffstat (limited to 'bdb/docs/ref/program')
| -rw-r--r-- | bdb/docs/ref/program/appsignals.html | 35 | ||||
| -rw-r--r-- | bdb/docs/ref/program/byteorder.html | 31 | ||||
| -rw-r--r-- | bdb/docs/ref/program/compatible.html | 32 | ||||
| -rw-r--r-- | bdb/docs/ref/program/copy.html | 63 | ||||
| -rw-r--r-- | bdb/docs/ref/program/dbsizes.html | 45 | ||||
| -rw-r--r-- | bdb/docs/ref/program/diskspace.html | 145 | ||||
| -rw-r--r-- | bdb/docs/ref/program/environ.html | 33 | ||||
| -rw-r--r-- | bdb/docs/ref/program/errorret.html | 108 | ||||
| -rw-r--r-- | bdb/docs/ref/program/extending.html | 242 | ||||
| -rw-r--r-- | bdb/docs/ref/program/mt.html | 95 | ||||
| -rw-r--r-- | bdb/docs/ref/program/namespace.html | 44 | ||||
| -rw-r--r-- | bdb/docs/ref/program/recimp.html | 49 | ||||
| -rw-r--r-- | bdb/docs/ref/program/runtime.html | 57 | ||||
| -rw-r--r-- | bdb/docs/ref/program/scope.html | 71 | ||||
| -rw-r--r-- | bdb/docs/ref/program/solaris.txt | 213 | ||||
| -rw-r--r-- | bdb/docs/ref/program/version.html | 45 |
16 files changed, 0 insertions, 1308 deletions
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 @@ -<!--$Id: appsignals.so,v 10.25 2000/07/15 15:49:07 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Application signal handling</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/xa/faq.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/errorret.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Application signal handling</h1> -<p>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. -<p>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. -<table><tr><td><br></td><td width="1%"><a href="../../ref/xa/faq.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/errorret.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: byteorder.so,v 10.20 2000/03/18 21:43:15 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Byte ordering</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> <a name="3"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/dbsizes.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/diskspace.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Byte ordering</h1> -<p>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. -<p>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. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/dbsizes.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/diskspace.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: compatible.so,v 10.29 2000/07/25 16:31:19 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Compatibility with historic interfaces</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/diskspace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/recimp.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Compatibility with historic interfaces</h1> -<p>The Berkeley DB version 2 library provides backward compatible interfaces for -the historic UNIX <a href="../../api_c/dbm.html">dbm</a>, <a href="../../api_c/dbm.html">ndbm</a> and <a href="../../api_c/hsearch.html">hsearch</a> -interfaces. It also provides a backward compatible interface for the -historic Berkeley DB 1.85 release. -<p>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 <a href="../../utility/db_dump.html">db_dump185</a> and <a href="../../utility/db_load.html">db_load</a> information. -No utilities are provided to convert UNIX <a href="../../api_c/dbm.html">dbm</a>, <a href="../../api_c/dbm.html">ndbm</a> or -<a href="../../api_c/hsearch.html">hsearch</a> databases. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/diskspace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/recimp.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: copy.so,v 10.4 2000/03/18 21:43:15 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Copying databases</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/namespace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/version.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Copying databases</h1> -<p>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. -<p>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 -<a href="../../api_c/db_close.html">DB->close</a> is called. Nor is there a Berkeley DB interface to explicitly -discard pages from the shared memory buffer pool for any particular -database. -<p>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 <a href="../../api_c/db_sync.html">DB->sync</a> or <a href="../../api_c/db_close.html">DB->close</a> interfaces. -<p>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: -<p><ol> -<p><li>Remove the environment, either explicitly or by calling <a href="../../api_c/env_remove.html">DBENV->remove</a>. -Note, this will not allow you to access both the original and copy of the -database at the same time. -<p><li>Overwrite the bytestring in the copied database with a new bytestring. -This allows you to access both the original and copy of the database at -the same time. -<p><li>Create a new file that will have a new bytestring. The simplest -way to create a new file that will have a new bytestring is to call the -<a href="../../utility/db_dump.html">db_dump</a> utility to dump out the contents of the database, and then -use the <a href="../../utility/db_load.html">db_load</a> utility to load the dumped output into a new file -name. This allows you to access both the original and copy of the -database at the same time. -</ol> -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/namespace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/version.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: dbsizes.so,v 10.22 2000/03/18 21:43:16 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Database limits</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/version.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/byteorder.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Database limits</h1> -<p>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 2<sup>48</sup> (256 terabytes). The -minimum database page size is 512 bytes, which results in a minimum -maximum database size of 2<sup>41</sup> (2 terabytes). -<p>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 -2<sup>32</sup>, including the ability to seek to absolute offsets within -those files. -<p>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. -<p>The maximum Btree depth is 255. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/version.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/byteorder.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: diskspace.so,v 10.9 2000/03/22 21:56:11 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Disk space requirements</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/byteorder.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/compatible.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Disk space requirements</h1> -<p>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. -<p>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. -<p>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. -<h3>Btree</h3> -<p>The formulas for the Btree access method are as follows: -<p><blockquote><pre>useful-bytes-per-page = (page-size - page-overhead) * page-fill-factor -<p> -bytes-of-data = n-records * - (bytes-per-entry + page-overhead-for-two-entries) -<p> -n-pages-of-data = bytes-of-data / bytes-per-page -<p> -total-pages-on-disk = n-pages-of-data * page-size -</pre></blockquote> -<p>The <b>useful-bytes-per-page</b> 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 <b>page-fill-factor</b> 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 -<a href="../../utility/db_stat.html">db_stat</a> utility. -<p>As an example, using an 8K page size, with an 85% page-fill factor, there -are 6941 bytes of useful space on each page: -<p><blockquote><pre>6941 = (8192 - 26) * .85</pre></blockquote> -<p>The total <b>bytes-of-data</b> 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: -<p><blockquote><pre>1560000000 = 60000000 * ((8 * 2) + (5 * 2))</pre></blockquote> -<p>The total pages of data, <b>n-pages-of-data</b>, is the -<b>bytes-of-data</b> divided by the <b>useful-bytes-per-page</b>. In -the example, there are 224751 pages of data. -<p><blockquote><pre>224751 = 1560000000 / 6941</pre></blockquote> -<p>The total bytes of disk space for the database is <b>n-pages-of-data</b> -multiplied by the <b>page-size</b>. In the example, the result is -1841160192 bytes, or roughly 1.71GB. -<p><blockquote><pre>1841160192 = 224751 * 8192</pre></blockquote> -<h3>Hash</h3> -<p>The formulas for the Hash access method are as follows: -<p><blockquote><pre>useful-bytes-per-page = (page-size - page-overhead) -<p> -bytes-of-data = n-records * - (bytes-per-entry + page-overhead-for-two-entries) -<p> -n-pages-of-data = bytes-of-data / bytes-per-page -<p> -total-pages-on-disk = n-pages-of-data * page-size -</pre></blockquote> -<p>The <b>useful-bytes-per-page</b> 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. -<p>As an example, using an 8K page size, there are 8166 bytes of useful space -on each page: -<p><blockquote><pre>8166 = (8192 - 26)</pre></blockquote> -<p>The total <b>bytes-of-data</b> 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: -<p><blockquote><pre>1320000000 = 60000000 * ((16 + 6))</pre></blockquote> -<p>The total pages of data, <b>n-pages-of-data</b>, is the -<b>bytes-of-data</b> divided by the <b>useful-bytes-per-page</b>. In -this example, there are 161646 pages of data. -<p><blockquote><pre>161646 = 1320000000 / 8166</pre></blockquote> -<p>The total bytes of disk space for the database is <b>n-pages-of-data</b> -multiplied by the <b>page-size</b>. In the example, the result is -1324204032 bytes, or roughly 1.23GB. -<p><blockquote><pre>1324204032 = 161646 * 8192</pre></blockquote> -<p>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. -<p><blockquote><pre>371 = 8166 / 22</pre></blockquote> -<p>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. -<p><blockquote><pre>314 = 8166 / 26</pre></blockquote> -<p>With a fill factor of 314, then the formula for computing database size -is: -<p><blockquote><pre>npages = npairs / pairs-per-page</pre></blockquote> -<p>or 191082. -<p><blockquote><pre>191082 = 60000000 / 314</pre></blockquote> -<p>At 191082 pages, the total database size would be 1565343744 or 1.46GB. -<p><blockquote><pre>1565343744 = 191082 * 8192 </pre></blockquote> -<p>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. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/byteorder.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/compatible.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: environ.so,v 10.17 2000/03/18 21:43:16 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Environment variables</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/errorret.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/mt.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Environment variables</h1> -<p>The Berkeley DB library uses the following environment variables: -<p><dl compact> -<p><dt>DB_HOME<dd>If the environment variable DB_HOME is set, it is used as part of -<a href="../../ref/env/naming.html">File Naming</a>. -Note, for the DB_HOME variable to take effect, either the -<a href="../../api_c/env_open.html#DB_USE_ENVIRON">DB_USE_ENVIRON</a> or <a href="../../api_c/env_open.html#DB_USE_ENVIRON_ROOT">DB_USE_ENVIRON_ROOT</a> flags must be -specified to <a href="../../api_c/env_open.html">DBENV->open</a>. -<p><dt>TMPDIR, TEMP, TMP, TempFolder<dd>The TMPDIR, TEMP, TMP and TempFolder environment variables are all -checked as locations in which to create temporary files. See -<a href="../../api_c/env_set_tmp_dir.html">DBENV->set_tmp_dir</a> for more information. -</dl> -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/errorret.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/mt.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: errorret.so,v 10.34 2000/12/31 19:26:21 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Error returns to applications</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/appsignals.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/environ.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Error returns to applications</h1> -<p>Except for the historic <a href="../../api_c/dbm.html">dbm</a>, <a href="../../api_c/dbm.html">ndbm</a> and <a href="../../api_c/hsearch.html">hsearch</a> -interfaces, Berkeley DB does not use the global variable <b>errno</b> to -return error values. The return values for all Berkeley DB functions are -grouped into three categories: -<p><dl compact> -<p><dt>0<dd>A return value of 0 indicates that the operation was successful. -<p><dt>> 0<dd>A return value that is greater than 0 indicates that there was a system -error. The <b>errno</b> value returned by the system is returned by -the function, e.g., when a Berkeley DB function is unable to allocate memory, -the return value from the function will be ENOMEM. -<p><dt>< 0<dd>A return value that is less than 0 indicates a condition that was not -a system failure, but was not an unqualified success, either. For -example, a routine to retrieve a key/data pair from the database may -return DB_NOTFOUND when the key/data pair does not appear in -the database, as opposed to the value of 0, which would be returned if -the key/data pair were found in the database. -<p> <a name="3"><!--meow--></a> -All values returned by Berkeley DB functions are less than 0 in order to avoid -conflict with possible values of <b>errno</b>. 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. -</dl> -While possible error returns are specified by each individual function's -manual page, there are a few error returns that deserve special mention: -<h3><a name="DB_NOTFOUND">DB_NOTFOUND</a> and <a name="DB_KEYEMPTY">DB_KEYEMPTY</a></h3> -<p>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. -<p>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. -<p>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 <a href="../../api_c/db_open.html">DB->open</a> 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. -<h3><a name="DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a></h3> -<p>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. -<p>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. -<h3><a name="DB_LOCK_NOTGRANTED">DB_LOCK_NOTGRANTED</a></h3> -<p>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. -<h3><a name="DB_RUNRECOVERY">DB_RUNRECOVERY</a></h3> -<p>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.) -<p>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. -<p>Optionally, applications may also specify a fatal-error callback function -using the <a href="../../api_c/env_set_paniccall.html">DBENV->set_paniccall</a> function. This callback function will be -called with two arguments: a reference to the DB_ENV structure associated -with the environment, and the <b>errno</b> value associated with the -underlying error that caused the problem. -<p>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. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/appsignals.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/environ.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: extending.so,v 10.32 2000/07/25 16:31:19 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Application-specific logging and recovery</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/recimp.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/runtime.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Application-specific logging and recovery</h1> -<p>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. -<h3>Defining Application-Specific Operations</h3> -<p>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. -<p>All lines beginning with a hash character in <b>.src</b> files are -treated as comments. -<p>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 -<b>.src</b> file. -<p>The rest of the file consists of one or more log record descriptions. -Each log record description begins with the line: -<p><blockquote><pre>BEGIN RECORD_NAME RECORD_NUMBER</pre></blockquote> -<p>and ends with the line: -<p><blockquote><pre>END</pre></blockquote> -<p>The RECORD_NAME keyword should be replaced with a unique record name for -this log record. Record names must only be unique within <b>.src</b> -files. -<p>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. -<p>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: -<p><blockquote><pre>ARG | DBT | POINTER variable_name variable_type printf_format</pre></blockquote> -<p>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. -<p>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. -<h3>Automatically Generated Functions</h3> -<p>For each log record description found in the file, the following structure -declarations and #defines will be created in the file PREFIX_auto.h. -<p><blockquote><pre><p> -#define DB_PREFIX_RECORD_TYPE /* Integer ID number */ -<p> -typedef struct _PREFIX_RECORD_TYPE_args { - /* - * These three fields are generated for every record. - */ - u_int32_t type; /* Record type used for dispatch. */ -<p> - /* - * Transaction id that identifies the transaction on whose - * behalf the record is being logged. - */ - DB_TXN *txnid; -<p> - /* - * The LSN returned by the previous call to log for - * this transaction. - */ - DB_LSN *prev_lsn; -<p> - /* - * The rest of the structure contains one field for each of - * the entries in the record statement. - */ -};</pre></blockquote> -<p>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). -<p>In addition to the PREFIX_auto.h file, a file named PREFIX_auto.c is -created, containing the following functions for each record type: -<p><dl compact> -<p><dt>The log function, with the following parameters:<dd><p><dl compact> -<p><dt>dbenv<dd>The environment handle returned by <a href="../../api_c/env_create.html">db_env_create</a>. -<p><dt>txnid<dd>The transaction identifier returned by <a href="../../api_c/txn_begin.html">txn_begin</a>. -<p><dt>lsnp<dd>A pointer to storage for an LSN into which the LSN of the new log record -will be returned. -<p><dt>syncflag<dd>A flag indicating if the record must be written synchronously. Valid -values are 0 and <a href="../../api_c/log_put.html#DB_FLUSH">DB_FLUSH</a>. -</dl> -<p>The log function marshalls the parameters into a buffer and calls -<a href="../../api_c/log_put.html">log_put</a> on that buffer returning 0 on success and 1 on failure. -<p><dt>The read function with the following parameters:<dd> -<p><dl compact> -<p><dt>recbuf<dd>A buffer. -<p><dt>argp<dd>A pointer to a structure of the appropriate type. -</dl> -<p>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. -<p><dt>The recovery function with the following parameters:<dd><p><dl compact> -<p><dt>dbenv<dd>The handle returned from the <a href="../../api_c/env_create.html">db_env_create</a> call which identifies -the environment in which recovery is running. -<p><dt>rec<dd>The <b>rec</b> parameter is the record being recovered. -<p><dt>lsn<dd>The log sequence number of the record being recovered. -<p><dt>op<dd>A parameter of type db_recops which indicates what operation is being run -(DB_TXN_OPENFILES, DB_TXN_ABORT, DB_TXN_BACKWARD_ROLL, DB_TXN_FORWARD_ROLL). -<p><dt>info<dd>A structure passed by the dispatch function. It is used to contain a list -of committed transactions and information about files that may have been -deleted. -</dl> -<p>The recovery function is called on each record read from the log during -system recovery or transaction abort. -<p>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. -<p><dt>The print function:<dd>The print function takes the same parameters as the recover function so -that it is simple to dispatch both to simple print functions as well as -to the actual recovery functions. This is useful for debugging purposes -and is used by the <a href="../../utility/db_printlog.html">db_printlog</a> utility to produce a human-readable -version of the log. All parameters except the <b>rec</b> and -<b>lsnp</b> parameters are ignored. The <b>rec</b> parameter contains -the record to be printed. -</dl> -One additional function, an initialization function, -is created for each <b>.src</b> file. -<p><dl compact> -<p><dt>The initialization function has the following parameters:<dd><p><dl compact> -<p><dt>dbenv<dd>The environment handle returned by <a href="../../api_c/env_create.html">db_env_create</a>. -</dl> -<p>The recovery initialization function registers each log record type -declared with the recovery system, so that the appropriate function is -called during recovery. -</dl> -<h3>Using Automatically Generated Routines</h3> -<p>Applications use the automatically generated functions as follows: -<p><ol> -<p><li>When the application starts, -call the <a href="../../api_c/env_set_rec_init.html">DBENV->set_recovery_init</a> with your recovery -initialization function so that the initialization function is called -at the appropriate time. -<p><li>Issue a <a href="../../api_c/txn_begin.html">txn_begin</a> call before any operations you wish -to be transaction protected. -<p><li>Before accessing any data, issue the appropriate lock call to -lock the data (either for reading or writing). -<p><li>Before modifying any data that is transaction protected, issue -a call to the appropriate log function. -<p><li>Issue a <a href="../../api_c/txn_commit.html">txn_commit</a> to save all of the changes or a -<a href="../../api_c/txn_abort.html">txn_abort</a> to cancel all of the modifications. -</ol> -<p>The recovery functions (described below) can be called in two cases: -<p><ol> -<p><li>From the recovery daemon upon system failure, with op set to -DB_TXN_FORWARD_ROLL or DB_TXN_BACKWARD_ROLL. -<p><li>From <a href="../../api_c/txn_abort.html">txn_abort</a>, if it is called to abort a transaction, with -op set to DB_TXN_ABORT. -</ol> -<p>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. -<p>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. -<p>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. -<h3>Non-conformant Logging</h3> -<p>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. -<p>First, you must decide how you will dispatch your records. Encapsulate -this algorithm in a dispatch function that is passed to <a href="../../api_c/env_open.html">DBENV->open</a>. -The arguments for the dispatch function are as follows: -<p><dl compact> -<p><dt>dbenv<dd>The environment handle returned by <a href="../../api_c/env_create.html">db_env_create</a>. -<p><dt>rec<dd>The record being recovered. -<p><dt>lsn<dd>The log sequence number of the record to be recovered. -<p><dt>op<dd>Indicates what operation of recovery is needed (openfiles, abort, forward roll -or backward roll). -<p><dt>info<dd>An opaque value passed to your function during system recovery. -</dl> -<p>When you abort a transaction, <a href="../../api_c/txn_abort.html">txn_abort</a> 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. -<p>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). -<p>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 <a href="../../api_c/txn_begin.html">txn_begin</a> -and <a href="../../api_c/txn_commit.html">txn_commit</a>. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/recimp.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/runtime.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: mt.so,v 10.37 2000/12/04 18:05:42 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Building multi-threaded applications</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/environ.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/scope.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Building multi-threaded applications</h1> -<p>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. -<p>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. -<p>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. -<p>The following rules should be observed when using threads to -access the Berkeley DB library: -<p><ol> -<p><li>The <a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> flag must be specified to the <a href="../../api_c/env_open.html">DBENV->open</a> -and <a href="../../api_c/db_open.html">DB->open</a> functions if the Berkeley DB handles returned by those interfaces -will be used in the context of more than one thread. Setting the -<a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> flag inconsistently may result in database corruption. -<p>Threading is assumed in the Java API, so no special flags are required, -and Berkeley DB functions will always behave as if the <a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> flag -was specified. -<p>Only a single thread may call the <a href="../../api_c/env_close.html">DBENV->close</a> or <a href="../../api_c/db_close.html">DB->close</a> functions -for a returned environment or database handle. -<p>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. -<p><li>When using the non-cursor Berkeley DB calls to retrieve key/data items (e.g., -<a href="../../api_c/db_get.html">DB->get</a>), 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 <a href="../../api_c/db_open.html">DB->open</a>. This includes any use of the returned -DB handle, including by another thread of control within the -process. -<p>For this reason, if the <a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> handle was specified to the -<a href="../../api_c/db_open.html">DB->open</a> function, either <a href="../../api_c/dbt.html#DB_DBT_MALLOC">DB_DBT_MALLOC</a>, <a href="../../api_c/dbt.html#DB_DBT_REALLOC">DB_DBT_REALLOC</a> -or <a href="../../api_c/dbt.html#DB_DBT_USERMEM">DB_DBT_USERMEM</a> must be specified in the <a href="../../api_c/dbt.html">DBT</a> when -performing any non-cursor key or data retrieval. -<p><li>The <a href="../../api_c/dbc_get.html#DB_CURRENT">DB_CURRENT</a>, <a href="../../api_c/dbc_get.html#DB_NEXT">DB_NEXT</a> and <a href="../../api_c/dbc_get.html#DB_PREV">DB_PREV</a> flags to the -<a href="../../api_c/log_get.html">log_get</a> function may not be used by a free-threaded handle. If -such calls are necessary, a thread should explicitly create a unique -environment handle by separately calling <a href="../../api_c/env_open.html">DBENV->open</a> without -specifying <a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a>. -<p><li>Each database operation (i.e., any call to a function underlying the -handles returned by <a href="../../api_c/db_open.html">DB->open</a> and <a href="../../api_c/db_cursor.html">DB->cursor</a>) is normally -performed on behalf of a unique locker. If, within a single thread of -control, multiple calls on behalf of the same locker are desired, then -transactions must be used. For example, consider the case where a -cursor scan locates a record, and then based on that record, accesses -some other item in the database. If these operations are done using -the default lockers for the handle, they may conflict. If the -application wishes to guarantee that the operations do not conflict, -locks must be obtained on behalf of a transaction, instead of the -default locker ID, and a transaction must be specified to subsequent -<a href="../../api_c/db_cursor.html">DB->cursor</a> and other Berkeley DB calls. -<p><li>Transactions may not span threads. Each transaction must begin and end -in the same thread, and each transaction may only be used by a single -thread. -<p>Cursors may not span transactions or threads. Each cursor must be -allocated and de-allocated within the same transaction and within -the same thread. -<p><li>User-level synchronization mutexes must have been implemented for the -compiler/architecture combination. Attempting to specify the DB_THREAD -flag will fail if fast mutexes are not available. -<p>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. -<p>It is possible to specify a yield function on an per-application basis. -See <a href="../../api_c/set_func_yield.html">db_env_set_func_yield</a> for more information. -<p>It is possible to specify the number of attempts that will be made to -acquire the mutex before waiting. Se <a href="../../api_c/env_set_tas_spins.html">db_env_set_tas_spins</a> for -more information. -</ol> -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/environ.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/scope.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: namespace.so,v 10.14 2000/08/01 21:51:23 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Name spaces</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/scope.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/copy.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Name spaces</h1> -<p>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. -<p>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. -<p>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. -<p>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_". -<p>Berkeley DB environments create or use some number of files in environment home -directories. These files are named <a href="../../ref/env/naming.html#DB_CONFIG">DB_CONFIG</a>, "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. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/scope.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/copy.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: recimp.so,v 11.2 2000/03/18 21:43:18 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Recovery implementation</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Transaction Protected Applications</dl></h3></td> -<td width="1%"><a href="../../ref/transapp/filesys.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/reclimit.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Recovery implementation</h1> -<p>The physical recovery process works as follows: -<p>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. -<p>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. -<p>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. -<p>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. -<p>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. -<table><tr><td><br></td><td width="1%"><a href="../../ref/transapp/filesys.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/reclimit.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: runtime.so,v 10.23 2000/12/04 18:05:42 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Run-time configuration</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/extending.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/lock/intro.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Run-time configuration</h1> -<p>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: -<p><blockquote><pre><a href="../../api_c/set_func_close.html">db_env_set_func_close</a> -<a href="../../api_c/set_func_dirfree.html">db_env_set_func_dirfree</a> -<a href="../../api_c/set_func_dirlist.html">db_env_set_func_dirlist</a> -<a href="../../api_c/set_func_exists.html">db_env_set_func_exists</a> -<a href="../../api_c/set_func_free.html">db_env_set_func_free</a> -<a href="../../api_c/set_func_fsync.html">db_env_set_func_fsync</a> -<a href="../../api_c/set_func_ioinfo.html">db_env_set_func_ioinfo</a> -<a href="../../api_c/set_func_malloc.html">db_env_set_func_malloc</a> -<a href="../../api_c/set_func_map.html">db_env_set_func_map</a> -<a href="../../api_c/set_func_open.html">db_env_set_func_open</a> -<a href="../../api_c/set_func_read.html">db_env_set_func_read</a> -<a href="../../api_c/set_func_realloc.html">db_env_set_func_realloc</a> -<a href="../../api_c/set_func_seek.html">db_env_set_func_seek</a> -<a href="../../api_c/set_func_sleep.html">db_env_set_func_sleep</a> -<a href="../../api_c/set_func_unlink.html">db_env_set_func_unlink</a> -<a href="../../api_c/set_func_unmap.html">db_env_set_func_unmap</a> -<a href="../../api_c/set_func_write.html">db_env_set_func_write</a> -<a href="../../api_c/set_func_yield.html">db_env_set_func_yield</a></pre></blockquote> -<p>These interfaces are only available from the Berkeley DB C language API. -<p>In addition, there are a few interfaces that allow applications to -re-configure, on an application-wide basis, Berkeley DB behaviors. -<p><blockquote><pre><a href="../../api_c/env_set_mutexlocks.html">DBENV->set_mutexlocks</a> -<a href="../../api_c/env_set_pageyield.html">db_env_set_pageyield</a> -<a href="../../api_c/env_set_panicstate.html">db_env_set_panicstate</a> -<a href="../../api_c/env_set_region_init.html">db_env_set_region_init</a> -<a href="../../api_c/env_set_tas_spins.html">db_env_set_tas_spins</a></pre></blockquote> -<p>These interfaces are available from all of the Berkeley DB programmatic APIs. -<p>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. <a href="solaris.txt">Example code</a> that supports this is -included in the Berkeley DB distribution. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/extending.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/lock/intro.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: scope.so,v 10.3 2000/08/10 17:54:49 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Berkeley DB handles</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> - <a name="2"><!--meow--></a> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/mt.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/namespace.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Berkeley DB handles</h1> - <a name="3"><!--meow--></a> -<p>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. -<p><dl compact> -<p><dt>DB_ENV<dd>The DB_ENV handle is created by the <a href="../../api_c/env_create.html">db_env_create</a> function and -references a Berkeley DB database environment, a collection of -databases and Berkeley DB subsystems. DB_ENV handles are free-threaded -if the <a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> flag is specified to the <a href="../../api_c/env_open.html">DBENV->open</a> function -when the environment is opened. The handle should not be closed while -any other handle remains open that is using it as a reference -(e.g., DB or DB_TXN). Once either the <a href="../../api_c/env_close.html">DBENV->close</a> or -<a href="../../api_c/env_remove.html">DBENV->remove</a> functions are called, the handle may not be accessed again, -regardless of the function's return. -<p><dt>DB_TXN<dd>The DB_TXN handle is created by the <a href="../../api_c/txn_begin.html">txn_begin</a> function and -references a single transaction. The handle is not free-threaded, and -transactions may not span threads nor may transactions be used by more -than a single thread. -Once the -<a href="../../api_c/txn_abort.html">txn_abort</a> or <a href="../../api_c/txn_commit.html">txn_commit</a> functions are called, the handle may -not be accessed again, regardless of the function's return. -In addition, parent transactions may not issue -any Berkeley DB operations, except for <a href="../../api_c/txn_begin.html">txn_begin</a>, <a href="../../api_c/txn_abort.html">txn_abort</a> -and <a href="../../api_c/txn_commit.html">txn_commit</a>, while it has active child transactions (child -transactions that have not yet been committed or aborted). -<p><dt>DB_MPOOLFILE<dd>The DB_MPOOLFILE handle references an open file in the shared -memory buffer pool of the database environment. The handle is not -free-threaded. Once the <a href="../../api_c/memp_fclose.html">memp_fclose</a> function is called, the handle may -not be accessed again, regardless of the function's return. -<p><dt>DB<dd>The DB handle is created by the <a href="../../api_c/db_create.html">db_create</a> function and -references a single Berkeley DB database, which may or may not be part of a -database environment. DB handles are free-threaded if the -<a href="../../api_c/env_open.html#DB_THREAD">DB_THREAD</a> flag is specified to the <a href="../../api_c/db_open.html">DB->open</a> function when the -database is opened, or if the database environment in which the database -is opened is free-threaded. The handle should not be closed while any -other handle that references the database is in use, e.g., database -handles must not be closed while cursor handles into the database remain -open, or transactions which include operations on the database have not -yet been committed or aborted. Once the <a href="../../api_c/db_close.html">DB->close</a>, -<a href="../../api_c/db_remove.html">DB->remove</a> or <a href="../../api_c/db_rename.html">DB->rename</a> functions are called, the handle may -not be accessed again, regardless of the function's return. -<p><dt>DBC<dd>The DBC handle references a cursor into a Berkeley DB database. The -handle is not free-threaded and cursors may not span threads nor may -cursors be used by more than a single thread. If the cursor is to be -used to perform operations on behalf of a transaction, the cursor must -be opened and closed within the context of that single transaction. -Once <a href="../../api_c/dbc_close.html">DBcursor->c_close</a> has been called, the handle may not be accessed -again, regardless of the function's return. -</dl> -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/mt.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/namespace.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> 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 @@ -<!--$Id: version.so,v 10.14 2000/03/18 21:43:16 bostic Exp $--> -<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> -<!--All rights reserved.--> -<html> -<head> -<title>Berkeley DB Reference Guide: Library version information</title> -<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> -<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> -</head> -<body bgcolor=white> -<table><tr valign=top> -<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Programmer Notes</dl></h3></td> -<td width="1%"><a href="../../ref/program/copy.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p> -<h1 align=center>Library version information</h1> -<p>Each release of the Berkeley DB library has a major version number, a minor -version number, and a patch number. -<p>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. -<p>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). -<p>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. -<p>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. -<p>To retrieve the Berkeley DB version information, applications should use the -<a href="../../api_c/env_version.html">db_version</a> interface. In addition to the above information, the -<a href="../../api_c/env_version.html">db_version</a> interface returns a string encapsulating the version -information, suitable for display to a user. -<table><tr><td><br></td><td width="1%"><a href="../../ref/program/copy.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/program/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a> -</td></tr></table> -<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> -</body> -</html> |