nesting transactions in lmdb

lmdb is a key value store
a set of keys could be spread over different dbis, or in 1 dbi, or in the only unnamed dbi.
one way to imagine keys is like dashes, sprinkled in empty black space (which is the env), and when a txn targets to update a set of keys transactionally, the involved keys glow orange
a transaction provides a consistent view of the data, like a snapshot of the data (, at the moment that transaction was created?)
if i want to read a set of keys. i don't want any of them to mutate until i'm done reading all of them.
if there's an active writer nevertheless, mutating the same keys as i'm reading, it's doing that elsewhere, in a manner that's not corrupting my view.
what decides what keys go into what set? a domainland usecase
could there be a domainland example, where a transaction is not cleanly independent, but dependent on other transaction to commit first.
how are transactions composed, when one depends on another?

Once a single read-write transaction is opened, all further attempts to begin one will block until the first one is committed or aborted.

then i can't see, how do we use the nested transaction feature, because we can't nest one write transaction inside the other. maybe it is allowed for RW transactions that are made child of that RW transaction.

now creation of a txn-handle is not like creating a description in the zio sense, that it will be executed later. when we create the txn handle, and use it in mdb_get or mdb_put operations, the modifications are happening underneath, as the method gets called, directly in the memory mapped file. it's just that until the txn is committed, its changes aren't visible in the db.

but when we have zioland at our disposal, we can toy around with mere descriptions of lmdbland types, and compose them around, until we arrive at an optimized description that we can send into lmdbland for execution.

ripland so, to nest one txn handle, with another, i need and to create a nest, i can only tell what the parent

sidnt / lmdz

nesting transactions in lmdb #46