David Barbour wrote:
At the moment, LMDB provides a means to view the last committed transaction on the environment, but does not provide any means to reliably acquire the ID for the 'current' transaction. I cannot check that the `me_last_txnid` returned from mdb_envinfo() is the same snapshot I'm looking at.
I can think of several scenarios where accessing the transaction ID specific to the snapshot a transaction is viewing could be very useful.
First, if I want to promote a read-only transaction to a read-write transaction, a very simple mechanism is to abort the read, create the read-write transaction and compare the transaction IDs. If they're the same, I can immediately continue since there is no risk of any changes. Otherwise, I can restart the transaction with write enabled.
Second, if I want to build a layer above LMDB modeling concurrent read-write transactions, I can potentially track (in several read-only transactions) intended writes together with a bloom-filter for the keys I've read. (There are other ways to do this, too, e.g. via a proper STM layer.) It is feasible to logically serialize and merge a bunch of non-conflicting write transactions as one larger write transaction. Such a layer can potentially improve throughput and amortize synchronization costs, albeit with a tradeoff for memory overheads and latency.
Third, if I want to poll the database, the ability to peek at the transaction ID and see that nothing has changed could be very useful. In an HTTP server, the transaction ID could serve as an (admittedly coarse grained) e-tag.
Fortunately, implementing this feature request is trivial. It uses only information we already have: mt_txnid. I'm asking for access to this value, e.g. via:
txnid_t mdb_txn_id(MDB_txn* txn);Will you make this happen?
Seems like a reasonable request. Please submit the enhancement request to the ITS. Bonus points if you include a patch implementing the feature.