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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
