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?