On Fri, Dec 11, 2015 at 3:37 AM, Howard Chu <hyc@symas.com> wrote:

> abort is the way to end *any* transaction whose operations you wish to discard.

> commit is the way to end *any* transaction whose operations you wish to persist.

If one is to interpret DBI handles as entities that can be created, persisted and discarded by transactions, then this interpretation is difficult to reconcile with the fact that this can be done by a read-only transaction.

This interpretation is even more problematic if one considers that a transaction, including a read-only transaction, can discard entities it never created to begin with.

At a more fundamental level, LMDB is said to support "multiple sub-databases [...] with transactions covering all sub-databases" [1]. However, LMDB's API with respect to sub-databases and transactions is not orthogonal [2]. With an orthogonal API, a DBI handle would remain valid as long as the underlying sub-database existed, regardless of commits and aborts in transactions using it.

Now, I am not saying that LMDB must be orthogonal in that sense. This is definitely a design choice, and there may be good reasons why it is impossible or difficult for LMDB to behave that way. What I am saying, however, is that such a mode would be very nice to have, if it is not too difficult to implement. It could be requested by a flag passed to, preferably, mdb_dbi_open or to mdb_txn_begin.

> If you open a DBI in a read-only transaction and you want that DBI to persist after ending the transaction, then commit the transaction.

Can you confirm that, with read-only transactions, the only difference between commit and abort is in the way the associated DBI handles are treated, and, specifically, that no observable effect on performance will occur? If that is so, a note in the documentation stating this would be very helpful.

Cheers,

V.