berkeleyDB使用经验总结

多线程

Building multi-threaded applications

The Berkeley DB library is not itself multi-threaded. The library was deliberately architected to not use threads internally because of the portability problems that using threads within the library would introduce.

Berkeley DB内部是不支持多线程的，考虑到移植性的问题，其内部架构并没有使用多线程机制

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.

但是在Berkeley DB提供的接口中是支持多线程的，也就是说其多线程的支持是靠api来完成的？

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中使用多线程，需要注意下面的问题

1. The flag must be specified to the and functions if the Berkeley DB handles returned by those interfaces will be used in the context of more than one thread. Setting the flag inconsistently may result in database corruption.                DB_THREAD标志必须在DBENV->open和DB->open调用中设置DB_THEAD，否则可能导致inconsistent
   

   Threading is assumed in the Java API, so no special flags are required, and Berkeley DB functions will always behave as if the flag was specified.

   Only a single thread may call the or functions for a returned environment or database handle.

   No other Berkeley DB handles are free-threaded, for example, cursors and transactions may not span threads as their returned handles are not free-threaded.

2. When using the non-cursor Berkeley DB calls to retrieve key/data items (e.g., ), 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 . This includes any use of the returned DB handle, including by another thread of control within the process.       当使用非游标式的api进行数据检索使需要注意的问题
   

   For this reason, if the handle was specified to the function, either , or must be specified in the when performing any non-cursor key or data retrieval.

3. The , and flags to the 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 without specifying .
4. Each database operation (i.e., any call to a function underlying the handles returned by and DB->cursor) 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 DB->cursor and other Berkeley DB calls.        在某个线程中同样会出现数据同步的问题,考虑下面的一种情况：使用游标检索到某一个record，这时会取得这个record的lock(我们称这个过程为A)，然后根据这个record里面的数据在去数据库里面再去获取相关record B ，在过程A完成到获取record B之间，如果有其他操作对record B进行了修改，那么你获取到的数据将出现inconsistent，这时应该使用transacion来保证这一系列操作的完整性。              更通俗的将，就是如果你的操作范围大于了BDB自身所保证的数据lock的范围，为了保证这个操作的完整性，就应该使用transaction
   
5. 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.      transaction不能跨线程
   

   Cursors may not span transactions or threads. Each cursor must be allocated and de-allocated within the same transaction and within the same thread.      游标不能跨事务和线程
   

6. 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 where it will be more efficient to explicitly yield the processor to another thread.

   It is possible to specify a yield function on an per-application basis. See for more information.

   It is possible to specify the number of attempts that will be made to acquire the mutex before waiting. Se for more information.

多线程和事务的代码示例请看这里http://blog.chinaunix.net/u3/99156/showart.php?id=2237494