> On 2020-12-03, at 19:17:46, Howard Chu <[email protected]> wrote: > > Gábor Melis wrote: >> On Wed, 2 Dec 2020 at 22:50, james anderson >> <[email protected]> wrote: >>> >>> >>>> On 2020-12-02, at 22:53:58, Howard Chu <[email protected]> wrote: >>>> >>>> James Anderson wrote: >>>>> the mdb_env_open documentation includes in its note about NOTLS, that >>>>> >>>>> A read-only transaction may span threads if the user synchronizes its >>>>> use. >>>>> >>>>> to which read-only operations would this constraint apply? >>>> >>>> It depends. >>>> >>>> The only safe approach is to ensure that a txn is not active simultaneously >>>> in multiple threads. >>> >>> where “active” includes read-only cursors? >>> >>> does mean, either one constrains the threads such that there can be no >>> parallel access to the database, or each thread must establish its own >>> transaction, in which case there is no guarantee that they operate om the >>> same database state? >> >> Chiming in here, a cleaner api could be to allow starting a >> transaction with a given txn id. That way one would have separate >> transaction objects, but consistent state. The client code would need >> to synchronize threads a bit to guarantee that the txn id is still >> valid, but this would be more lightweight and easier to reason about. > > In an actively written database there is no legitimate use case for > opening a new transaction on anything but the newest version of the > data. Reading or depending on stale data would be an application bug.
without considering the relation between that notion and the management of data in a bitemporal store, the question remains, how are two independent threads to ensure that they are reading the same “newest” version when some other, likewise independent, process may commit a write transaction in the time interval between the instants of the respective read transaction begins? --- james anderson | [email protected] | http://dydra.com
