Hi,

I am trying to figure out the best way to design the DB layer in my
application to use BerkeleyDB. The requirements are:

(1) Multiple processes need to interact with Berkeley DB.
(2) Potentially, in future, multiple threads within a separate process
need to interact with Berkeley DB.
(3) The processes and threads are concurrent, need to be transaction
protected, additionally they need to share locks, e.g. when one process
locks (read/write) an object other processes/threads need to
block/timeout.
(4) Each process/thread open/close its own transaction(s) and cursor(s)
as necessary.
(5) All threads and processes need to operate on the same set of
databases.

In short, my application requirement is concurrent+transactional data
store.

It is important to realize that all applications sharing a database
environment implicitly trust each other. They have access to each
other's data as it resides in the shared regions, and they will share
resources such as buffer space and locks. At the same time, any
applications using the same databases must share an environment if
consistency is to be maintained between them.
==============================

Q1: From the above, can I assume that there can be only one environment
(DB_ENV) handle to be shared for all processes and threads for my
application?

Q2: Can all of the above requirements (1-5) be satisfied through
DB_REGISTER flag? If the answer to Q1 is YES, I guess the answer to Q2
will be NO since DB_REGISTER flag is only during opening an environment
by a process.

Thanks in advance.

Gursoz.

Gursoz,

You should not confuse a single DB_ENV handle with a single
environment. An environment is opened by calling the DB_ENV->open
method using an environment handle. Each process must have its own
handle. Handles cannot be shared amoung processes but may be shared
among threads within a process.

The use of DB_REGISTER is orthoganl to the requirement that sharing a
database implies sharing an enviornment. You can use the DB_REGISTER
flag if your processes are not controled and/or montitored by a single
process as described in the reference guide:
http://www.sleepycat.com/docs/ref/transapp/app.html

Michael Ubell
Sleepycat Software.