Berkeley DB fully supports multithreaded applications. The Berkeley DB library is -not itself multithreaded, and was deliberately architected to not use -threads internally because of the portability problems that would -introduce. Database environment and database object handles returned -from Berkeley DB library functions are free-threaded. No other object handles -returned from the Berkeley DB library are free-threaded. The following rules -should be observed when using threads to access the Berkeley DB library:

+ Berkeley DB fully supports multithreaded applications. The + Berkeley DB library is not itself multithreaded, and was + deliberately architected to not use threads internally because + of the portability problems that would introduce. Database + environment and database object handles returned from Berkeley + DB library functions are free-threaded. No other object + handles returned from the Berkeley DB library are + free-threaded. The following rules should be observed when + using threads to access the Berkeley DB library: +

Prev	Chapter 15. - Programmer Notes -	Chapter 15. Programmer Notes	Next

-
The DB_THREAD flag must be specified to the DB_ENV->open() -and DB->open() methods if the Berkeley DB handles returned by those interfaces -will be used in the context of more than one thread. Setting the -DB_THREAD flag inconsistently may result in database corruption. -
-
Threading is assumed in the Java API, so no special flags are required; -and Berkeley DB functions will always behave as if the DB_THREAD flag -was specified.
-
Only a single thread may call the DB_ENV->close() or DB->close() methods -for a returned environment or database handle.
-
No other Berkeley DB handles are free-threaded.
+
+ The DB_THREAD flag must be specified to the + DB_ENV->open() and DB->open() methods if the Berkeley DB + handles returned by those interfaces will be used in + the context of more than one thread. Setting the + DB_THREAD flag inconsistently may result in database + corruption. +
+
+ Threading is assumed in the Java API, so no special + flags are required; and Berkeley DB functions will + always behave as if the DB_THREAD flag was + specified. +
+
+ Only a single thread may call the DB_ENV->close() or + DB->close() methods for a returned environment or + database handle. +
+
+ No other Berkeley DB handles are + free-threaded. +
+
+ When using the non-cursor Berkeley DB calls to + retrieve key/data items (for example, DB->get()), the + memory to which the pointer stored into the Dbt refers + is valid only until the next call using the DB + handle returned by DB->open(). This includes any use of the returned + DB handle, including by another thread within the + process. +

- When using the non-cursor Berkeley DB calls to retrieve key/data items - (for example, DB->get()), the memory to which the pointer stored into the - Dbt refers is valid only until the next call using the DB - handle returned by DB->open(). This includes any use of the returned DB handle, - including by another thread within the process. -
-
For this reason, if the DB_THREAD handle was specified to the -DB->open() method, either DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM -must be specified in the DBT when -performing any non-cursor key or data retrieval.
+ For this reason, if the DB_THREAD handle was + specified to the DB->open() method, either + DB_DBT_MALLOC, DB_DBT_REALLOC or DB_DBT_USERMEM + must be specified in the DBT when performing any + non-cursor key or data retrieval. +
-
Cursors may not span transactions. Each cursor must be - allocated and deallocated within the same transaction.
-
Transactions and cursors may span threads, but only serially, that is, -the application must serialize access to the TXN and -DBC handles. In the case of nested transactions, since all -child transactions are part of the same parent transaction, they must observe -the same constraints. That is, children may execute in different threads -only if each child executes serially.
+
+ Cursors may not span transactions. Each cursor must + be allocated and deallocated within the same + transaction. +
+
+ Transactions and cursors may span threads, but only + serially, that is, the application must serialize + access to the TXN and DBC handles. In the case of + nested transactions, since all child transactions are + part of the same parent transaction, they must observe + the same constraints. That is, children may execute in + different threads only if each child executes + serially. +
-
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. -
-
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, in -which it is usually more efficient to explicitly yield the processor to -another thread.
-
It is possible to specify a yield function on an per-application basis. -See db_env_set_func_yield for more information.
-
It is possible to specify the number of attempts that will be made to -acquire the mutex before waiting. See DB_ENV->mutex_set_tas_spins() for -more information.
+
+ 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. +
+
+ 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, in which it is usually more efficient to + explicitly yield the processor to another + thread. +
+
+ It is possible to specify a yield function on an + per-application basis. See db_env_set_func_yield for more + information. +
+
+ It is possible to specify the number of attempts + that will be made to acquire the mutex before waiting. + See DB_ENV->mutex_set_tas_spins() for more information. +

When creating multiple databases in a single physical file, multithreaded -programs may have additional requirements. For more information, see -Opening multiple databases in a single file

+ When creating multiple databases in a single physical file, + multithreaded programs may have additional requirements. For + more information, see Opening multiple databases in a + single file +