I have developed an application using BDB where I have a multi-threaded process writing to an environment with multiple DBs, and another non-threaded process which only reads the DBs. I'm not using the DB_THREAD flag on the environment and DBs, but am controlling DB access in the threads with my own mutexes (since I was already doing that due a previous incarnation of my app which used Redis).
I guess my question is should I be using a Concurrent Data Store, or is my implementation 'safe'?
Concurrent Data Store is for the case where you have a single writer and multiple readers. From your description, it seems you have the opposite, multiple writers and a single reader. I do not believe that Concurrent Data Store will be a good fit for your application. I am assuming you are using Transactional Data Store right now and this will be a better fit for your application.
As a follow-on question, I've run into a situation where it seems my reader and writer processes are stepping on each other and locking up and I'm not sure what the best way to fix this is.
I'm writing lots of DBs in an environment, though only one DB at a time, Can my reader process open the DBs read-only to avoid any contention?
Yes - with concurrent data store, it is possible that the writer will block the readers. With CDS, it is best to have either the single writer or the multiple readers accessing the database at any given instant in time. If you do not do this from the application level, BDB will use locking to enforce this behavior. I would suggest reading through the Programmers reference guide, Chap 10, which covers a lot of information on CDS. This will give you better insight was to what is happening.
I was not using CDS at the time of my last post (Feb 1, 2014 4:56 PM), which describes my writing and reading processes both hanging. Since then, I have switched to CDS, and I have not experienced any hangs. My writer and reader processes are now getting along swimmingly.