Hallvard Breien Furuseth:
> Sofar the abstraction layer already hides the LMDB-specific
> 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 --
"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."
"[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
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
instead of several transactions. That also cures the "long-lived reader"
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.
Howard, maybe NOLOCK should keep the reader table and just drop the
locks? More work though.