I'm working with an application that 'pre-loads' a BDB file for use by
another application. The loader application is currently
single-threaded, and only writes new key/value pairs, there is no
'read-modify-write' cycle involved. Determining the values of the
key/value pair takes a fair amount of CPU, and thus writing to the BDB
(disk I/O) isn't the limiting factor. I'd like to explore what benefits
can be gained from going to a multi-threaded loader app, where multiple
threads would be writing to the BDB. Looking at

http://www.sleepycat.com/docs/ref/cam/intro.html

indicates that the Concurrent Data Store product is oriented toward
handing multiple readers and a single writer.

The simplest way to handle this would seem to be an application-level
mutex that would ensure that only one thread is writing at any one
time. This would also work well for the client I'm investigating this
for, as they're currently only licensed for the basic product, not the
Concurrent or Transactional products. The discussion at

http://groups.google.com/group/comp....0d5f6705c05f72

seems to indicate that that's a valid way to go.

Are there any other caveats to be aware of?

Thanks!
-nate

Hi Nate,

The basic idea would be to serialize so that you either have multiple
readers OR a single Writer. If there are read threads doing work you
will want the writer to block until all reads are completed (including
cursors).

The simplest way IMO is to use the Concurrent Data Store.

Ron