- Berkeley DB Reference Guide:
- Programmer Notes
|
|
Berkeley DB fully supports multithreaded applications. The Berkeley DB library is not itself multithreaded, as it was deliberately architected to not use threads internally because of the portability problems it 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:
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 functions for a returned environment or database handle.
No other Berkeley DB handles are free-threaded; for example, cursors and transactions may not span threads because their returned handles are not free-threaded.
For this reason, if the DB_THREAD handle was specified to the DB->open function, either DB_DBT_MALLOC, DB_DBT_REALLOC, or DB_DBT_USERMEM must be specified in the DBT when performing any non-cursor key or data retrieval.
Cursors may not span transactions or threads. Each cursor must be allocated and deallocated within the same transaction and within the same thread.
If blocking mutexes are available (for example POSIX pthreads), they will be used. Otherwise, the Berkeley DB library will make a system call to pause for some amount of time when it is necessary to wait on a lock. This may not be optimal, especially in a thread-only environment, in which it will be more efficient to explicitly yield the processor to another thread.
It is possible to specify a yield function on an per-application basis. See db_env_set_func_yield for more information.
It is possible to specify the number of attempts that will be made to acquire the mutex before waiting. See db_env_set_tas_spins for more information.
|
|
Copyright Sleepycat Software @ 1.1 log @Initial revision @ text @d1 1 a1 1 @ 1.1.1.1 log @Import: RPM 4.0.3 @ text @@ 1.1.1.2 log @Import: RPM 4.0.4 @ text @d1 1 a1 1 d40 1 a40 1 the Dbt refers is valid only until the next call using the DB d42 1 a42 1 the returned DB handle, including by another thread within the d48 5 d71 1 a71 1 acquire the mutex before waiting. See DB_ENV->set_tas_spins for @ 1.1.1.3 log @Import: RPM 4.0.5 @ text @d2 1 a2 1 a3 1 d27 1 a27 1 and DB->open methods if the Berkeley DB handles returned by those interfaces d33 1 a33 1
Only a single thread may call the DB_ENV->close or DB->close methods d40 1 a40 1 the Dbt refers is valid only until the next call using the DB d42 1 a42 1 the returned DB handle, including by another thread within the d45 2 a46 2 DB->open method, either DB_DBT_MALLOC, DB_DBT_REALLOC, or DB_DBT_USERMEM must be specified in the DBT when @ 1.1.1.4 log @Import: RPM 4.1 @ text @d2 1 a2 1 d4 1 d28 1 a28 1 and DB->open functions if the Berkeley DB handles returned by those interfaces d34 1 a34 1
Only a single thread may call the DB_ENV->close or DB->close functions d41 1 a41 1 the Dbt refers is valid only until the next call using the DB d43 1 a43 1 the returned DB handle, including by another thread within the d46 2 a47 2 DB->open function, either DB_DBT_MALLOC, DB_DBT_REALLOC, or DB_DBT_USERMEM must be specified in the DBT when @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d2 1 a2 1 a3 1 d27 1 a27 1 and DB->open methods if the Berkeley DB handles returned by those interfaces d33 1 a33 1
Only a single thread may call the DB_ENV->close or DB->close methods d40 1 a40 1 the Dbt refers is valid only until the next call using the DB d42 1 a42 1 the returned DB handle, including by another thread within the d45 2 a46 2 DB->open method, either DB_DBT_MALLOC, DB_DBT_REALLOC, or DB_DBT_USERMEM must be specified in the DBT when @