In the last message I posted, I noted that Durus appears to only support one
file per server process.
As one of my potential use cases for multi-process Durus involves having
more than one database open.  Furthermore, I may be creating new databases
on the fly.  Transactions would not cross database boundaries.

Perhaps a solution to my concurrency woes would be to create an extended
Durus server that operated in the same manner as the current Durus server,
but had some additional high-level operations.

Each client side process or thread would have a "service connection" that
would talk to the server.

The server would operate on a directory of Durus files, rather than an
individual file.

The client would create a "database connection" that would be mediated by
the service connection and have the same API as the current ClientStorage.
 Essentially, database-level operations would be tagged with the name or ID
of a database but would be formatted and acted upon in the same manner as a
single-database server.

The service connection would have some additional operations available:

- open a named database (creating it if it doesn't yet exist)
- close a named database
- destroy a named database
- list available database names
- list open database names

Thoughts?

--
Matthew R. Scott