Viacheslav Usov wrote:
On Fri, Dec 11, 2015 at 3:37 AM, Howard Chu <hyc@symas.com mailto: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.
A DBI handle is simply a slot in an in-memory array. Read-only transactions are read-only with respect to the database.
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.
No, no transaction can discard something that it didn't create.
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.
No. Aborting a transaction essentially means that no operation that was performed inside the transaction actually took place. Sub-DBs exist within the database regardless of whether any process has a DBI handle open on them.
Your statement is preposterous. It is the same as saying that file handles in an operating system must stay open as long as files exist in a filesystem. Utter nonsense.
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.
Nonsense.