Checking of Txn.ID() for lmdb.Readonly transactions now occurs at the correct location (as a Txn would enter the pool as opposed to when it exits the pool).
There is also an optimization that allows Txn.ID() to cache the value it gets for future calls. This requires some bookkeeping because there are times when a transaction's ID may change. But the logic behind this in LMDB is straight forward and there are some tests to make sure that Txn.ID() does transparently represent the value returned by mdb_txn_id.
Checking of Txn.ID() for lmdb.Readonly transactions now occurs at the correct location (as a Txn would enter the pool as opposed to when it exits the pool).
There is also an optimization that allows Txn.ID() to cache the value it gets for future calls. This requires some bookkeeping because there are times when a transaction's ID may change. But the logic behind this in LMDB is straight forward and there are some tests to make sure that Txn.ID() does transparently represent the value returned by
mdb_txn_id.