Edit File - File Manager

Edit File: db_set_flags.html

<html>
<head>
<title>Berkeley DB: DB-&gt;set_flags</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<table width="100%"><tr valign=top>
<td>
DB-&gt;set_flags
</td>
<td align=right>
<a href="../../db4-devel-4.7.25/api_c/api_core.html"><img src="../../db4-devel-4.7.25/images/api.gif" alt="API"></a>
<a href="../../db4-devel-4.7.25/ref/toc.html"><img src="../../db4-devel-4.7.25/images/ref.gif" alt="Ref"></a></td>
</tr></table>
<hr size=1 noshade>
<tt>
<pre>
#include &lt;db.h&gt;

int
DB-&gt;set_flags(DB *db, u_int32_t flags);

int
DB-&gt;get_flags(DB *db, u_int32_t *flagsp);
</pre>
<hr size=1 noshade>
Description: DB-&gt;set_flags
Configure a database. Calling DB-&gt;set_flags is additive; there
is no way to clear flags.
The DB-&gt;set_flags method may not be called after the <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> method is called.

The DB-&gt;set_flags method
returns a non-zero error value on failure
and 0 on success.

Parameters 
 flags<ul compact><li>The flags parameter must be set to 0 or by bitwise inclusively OR'ing together one
or more of the following values:
General
The following flags may be specified for any Berkeley DB access method:
 
<a name="2"></a>
<a name="DB_CHKSUM">DB_CHKSUM</a><ul compact><li>Do checksum verification of pages read into the cache from the backing
filestore. Berkeley DB uses the SHA1 Secure Hash Algorithm
if encryption is configured and a general hash algorithm if it is not.
Calling DB-&gt;set_flags with the DB_CHKSUM flag only affects the
specified <a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a> handle (and any other Berkeley DB handles opened within
the scope of that handle).
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_CHKSUM
flag
will be ignored.
If creating additional databases in a file, the checksum behavior specified
must be consistent with the existing databases in the file or an error will
be returned.</ul>
<a name="3"></a>
<a name="DB_ENCRYPT">DB_ENCRYPT</a><ul compact><li>Encrypt the database using the cryptographic password specified to the
<a href="../../db4-devel-4.7.25/api_c/env_set_encrypt.html">DB_ENV-&gt;set_encrypt</a> or <a href="../../db4-devel-4.7.25/api_c/db_set_encrypt.html">DB-&gt;set_encrypt</a> methods.
Calling DB-&gt;set_flags with the DB_ENCRYPT flag only affects the
specified <a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a> handle (and any other Berkeley DB handles opened within
the scope of that handle).
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_ENCRYPT
flag
must be the same as the existing database or an error
will be returned.

If creating additional databases in a file, the encryption behavior specified
must be consistent with the existing databases in the file or an error will
be returned.
Encrypted databases are not portable between machines of different byte
orders, that is, encrypted databases created on big-endian machines
cannot be read on little-endian machines, and vice versa.</ul>
<a name="4"></a>
<a name="DB_TXN_NOT_DURABLE">DB_TXN_NOT_DURABLE</a><ul compact><li>If set, Berkeley DB will not write log records for this database. This means
that updates of this database exhibit the ACI (atomicity, consistency,
and isolation) properties, but not D (durability); that is, database
integrity will be maintained, but if the application or system fails,
integrity will not persist. The database file must be verified and/or
restored from backup after a failure. In order to ensure integrity
after application shut down, the database handles must be closed without
specifying <a href="../../db4-devel-4.7.25/api_c/db_close.html#DB_NOSYNC">DB_NOSYNC</a>, or all database changes must be flushed
from the database environment cache using either the
<a href="../../db4-devel-4.7.25/api_c/txn_checkpoint.html">DB_ENV-&gt;txn_checkpoint</a> or <a href="../../db4-devel-4.7.25/api_c/memp_sync.html">DB_ENV-&gt;memp_sync</a> methods. All database handles for
a single physical file must set DB_TXN_NOT_DURABLE, including
database handles for different databases in a physical file.
Calling DB-&gt;set_flags with the DB_TXN_NOT_DURABLE flag only affects the
specified <a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a> handle (and any other Berkeley DB handles opened within
the scope of that handle).</ul>
 
Btree
The following flags may be specified for the Btree access method:
 
<a name="5"></a>
<a name="DB_DUP">DB_DUP</a><ul compact><li>Permit duplicate data items in the database; that is, insertion when the
key of the key/data pair being inserted already exists in the database
will be successful. The ordering of duplicates in the database is
determined by the order of insertion, unless the ordering is otherwise
specified by use of a cursor operation.
The DB_DUPSORT flag is preferred to DB_DUP for
performance reasons. The DB_DUP flag should only be used by
applications wanting to order duplicate data items manually.
Calling DB-&gt;set_flags with the DB_DUP flag affects the
database, including all threads of control accessing the database.
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_DUP
flag
must be the same as the existing database or an error
will be returned.

It is an error to specify both DB_DUP and DB_RECNUM.</ul>
<a name="6"></a>
<a name="DB_DUPSORT">DB_DUPSORT</a><ul compact><li>Permit duplicate data items in the database; that is, insertion when the
key of the key/data pair being inserted already exists in the database
will be successful. The ordering of duplicates in the database is
determined by the duplicate comparison function. If the application
does not specify a comparison function using the
<a href="../../db4-devel-4.7.25/api_c/db_set_dup_compare.html">DB-&gt;set_dup_compare</a> method, a default lexical comparison will be used.
It is an error to specify both DB_DUPSORT and DB_RECNUM.
Calling DB-&gt;set_flags with the DB_DUPSORT flag affects the
database, including all threads of control accessing the database.
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_DUPSORT
flag
must be the same as the existing database or an error
will be returned.
</ul>
<a name="7"></a>
<a name="DB_RECNUM">DB_RECNUM</a><ul compact><li>Support retrieval from the Btree using record numbers. For more
information, see the <a href="../../db4-devel-4.7.25/api_c/db_get.html#DB_SET_RECNO">DB_SET_RECNO</a> flag to the <a href="../../db4-devel-4.7.25/api_c/db_get.html">DB-&gt;get</a>
and <a href="../../db4-devel-4.7.25/api_c/dbc_get.html">DBcursor-&gt;get</a> methods.
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 database must be locked during both
insertions and deletions, effectively single-threading the database 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.
Calling DB-&gt;set_flags with the DB_RECNUM flag affects the
database, including all threads of control accessing the database.
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_RECNUM
flag
must be the same as the existing database or an error
will be returned.
</ul>
<a name="8"></a><a name="9"></a>
<a name="DB_REVSPLITOFF">DB_REVSPLITOFF</a><ul compact><li>Turn off reverse splitting in the Btree. As pages are emptied in a
database, the Berkeley DB Btree implementation attempts to coalesce empty pages
into higher-level pages in order to keep the database as small as possible
and minimize search time. This can hurt performance in applications
with cyclical data demands; that is, applications where the database grows
and shrinks repeatedly. For example, because Berkeley DB does page-level
locking, the maximum level of concurrency in a database of two pages is far
smaller than that in a database of 100 pages, so a database that has
shrunk to a minimal size can cause severe deadlocking when a new cycle of
data insertion begins.
Calling DB-&gt;set_flags with the DB_REVSPLITOFF flag only affects the
specified <a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a> handle (and any other Berkeley DB handles opened within
the scope of that handle).</ul>
 
Hash
The following flags may be specified for the Hash access method:
 
<a name="DB_DUP">DB_DUP</a><ul compact><li>Permit duplicate data items in the database; that is, insertion when the
key of the key/data pair being inserted already exists in the database
will be successful. The ordering of duplicates in the database is
determined by the order of insertion, unless the ordering is otherwise
specified by use of a cursor operation.
The DB_DUPSORT flag is preferred to DB_DUP for
performance reasons. The DB_DUP flag should only be used by
applications wanting to order duplicate data items manually.
Calling DB-&gt;set_flags with the DB_DUP flag affects the
database, including all threads of control accessing the database.
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_DUP
flag
must be the same as the existing database or an error
will be returned.

</ul>
<a name="DB_DUPSORT">DB_DUPSORT</a><ul compact><li>Permit duplicate data items in the database; that is, insertion when the
key of the key/data pair being inserted already exists in the database
will be successful. The ordering of duplicates in the database is
determined by the duplicate comparison function. If the application
does not specify a comparison function using the
<a href="../../db4-devel-4.7.25/api_c/db_set_dup_compare.html">DB-&gt;set_dup_compare</a> method, a default lexical comparison will be used.
It is an error to specify both DB_DUPSORT and DB_RECNUM.
Calling DB-&gt;set_flags with the DB_DUPSORT flag affects the
database, including all threads of control accessing the database.
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_DUPSORT
flag
must be the same as the existing database or an error
will be returned.
</ul>
 
Queue
The following flags may be specified for the Queue access method:
 
<a name="10"></a>
<a name="DB_INORDER">DB_INORDER</a><ul compact><li>The DB_INORDER flag modifies the operation of the
<a href="../../db4-devel-4.7.25/api_c/db_get.html#DB_CONSUME">DB_CONSUME</a> or <a href="../../db4-devel-4.7.25/api_c/db_get.html#DB_CONSUME_WAIT">DB_CONSUME_WAIT</a> flags to <a href="../../db4-devel-4.7.25/api_c/db_get.html">DB-&gt;get</a>
to return key/data pairs in order. That is, they will always return
the key/data item from the head of the queue.
The default behavior of queue databases is optimized for multiple
readers, and does not guarantee that record will be retrieved in the
order they are added to the queue. Specifically, if a writing thread
adds multiple records to an empty queue, reading threads may skip some
of the initial records when the next <a href="../../db4-devel-4.7.25/api_c/db_get.html">DB-&gt;get</a> call returns.
This flag modifies the <a href="../../db4-devel-4.7.25/api_c/db_get.html">DB-&gt;get</a> call to verify that the record
being returned is in fact the head of the queue. This will increase
contention and reduce concurrency when there are many reading threads.
Calling DB-&gt;set_flags with the DB_INORDER flag only affects the
specified <a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a> handle (and any other Berkeley DB handles opened within
the scope of that handle).</ul>
 
Recno
The following flags may be specified for the Recno access method:
 
<a name="11"></a>
<a name="DB_RENUMBER">DB_RENUMBER</a><ul compact><li>Specifying the DB_RENUMBER flag causes the logical record
numbers to be mutable, and change as records are added to and deleted
from the database. For example, the deletion of record number 4 causes
records numbered 5 and greater to be renumbered downward by one. If a
cursor was positioned to record number 4 before the deletion, it will
refer to the new record number 4, if any such record exists, after the
deletion. If a cursor was positioned after record number 4 before the
deletion, it will be shifted downward one logical record, continuing to
refer to the same record as it did before.
Using the <a href="../../db4-devel-4.7.25/api_c/db_put.html">DB-&gt;put</a> or <a href="../../db4-devel-4.7.25/api_c/dbc_put.html">DBcursor-&gt;put</a> 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 <a href="../../db4-devel-4.7.25/ref/program/errorret.html#DB_KEYEMPTY">DB_KEYEMPTY</a>.
If a created record is not at the end of the database, all records
following the new record will be automatically renumbered upward by one.
For example, the creation of a new record numbered 8 causes records
numbered 8 and greater to be renumbered upward by one. If a cursor was
positioned to record number 8 or greater before the insertion, it will be
shifted upward one logical record, continuing to refer to 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.
Calling DB-&gt;set_flags with the DB_RENUMBER flag affects the
database, including all threads of control accessing the database.
If the database already exists when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called, the DB_RENUMBER
flag
must be the same as the existing database or an error
will be returned.
</ul>
<a name="12"></a>
<a name="DB_SNAPSHOT">DB_SNAPSHOT</a><ul compact><li>This flag specifies that any specified re_source file be read
in its entirety when <a href="../../db4-devel-4.7.25/api_c/db_open.html">DB-&gt;open</a> is called. If this flag is not
specified, the re_source file may be read lazily.
Calling DB-&gt;set_flags with the DB_SNAPSHOT flag only affects the
specified <a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a> handle (and any other Berkeley DB handles opened within
the scope of that handle).</ul>
 </ul>
 
 Errors
The DB-&gt;set_flags method
may fail and return one of the following non-zero errors:
 
EINVAL<ul compact><li>An
invalid flag value or parameter was specified.</ul>
 
<hr size=1 noshade>
Description: DB-&gt;get_flags
The DB-&gt;get_flags method returns the current flags.
The DB-&gt;get_flags method may be called at any time during the life of the
application.
The DB-&gt;get_flags method
returns a non-zero error value on failure
and 0 on success.

Parameters 
 flagsp<ul compact><li>The DB-&gt;get_flags method returns the
current flags in flagsp.</ul>
 
<hr size=1 noshade>
 Class
<a href="../../db4-devel-4.7.25/api_c/db_class.html">DB</a>
 See Also
<a href="../../db4-devel-4.7.25/api_c/db_list.html">Databases and Related Methods</a>
</tt>
<table width="100%"><tr><td> </td><td align=right>
<a href="../../db4-devel-4.7.25/api_c/api_core.html"><img src="../../db4-devel-4.7.25/images/api.gif" alt="API"></a><a href="../../db4-devel-4.7.25/ref/toc.html"><img src="../../db4-devel-4.7.25/images/ref.gif" alt="Ref"></a>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

Back to File Manager