Hallvard Breien Furuseth:

...

Sofar the abstraction layer already hides the LMDB-specific MAP_FULL and MAP_RESIZED error conditions. If this abstraction layer needs additional code in order to maintain MDB cursor sanity, then please educate me.

ldmb.h says --

mdb_env_set_mapsize(): "It may be called at later times if no transactions are active in this process. Note that the library does not check for this condition, the caller must ensure it explicitly." MDB_NOLOCK: "[caller] must ensure that no readers are using old transactions while a writer is active. The simplest approach is to use an exclusive lock so that no readers may be active at all when a writer begins."

That's why I talked about saving the cursor position and restoring it - cursors are per-transaction and you need a new transaction.

I can remember the last key from mdb_cursor_get() and set the cursor to that key. There does not appear to be a cursor "save" operation in the API documentation http://symas.com/mdb/doc/group__mdb.html.

Maybe you should have a single write-transaction with several cursors, instead of several transactions. That also cures the "long-lived reader" problem.

That would result in delayed delete operations, and break correctness. If a database entry is updated after it is scheduled for delete, then the entry must not be deleted.

Also, I am concerned that would pollute my database-neutral API with LMDB-specific details.

Wietse

Howard, maybe NOLOCK should keep the reader table and just drop the locks? More work though.

-- Hallvard