> On 2020-12-03, at 23:40:18, Howard Chu <[email protected]> wrote: > > james anderson wrote: >> >>> 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? > > How would you do this in any other database system?
i would expect it to permit one of the alternatives which has been mentioned: - allow multiple threads to perform read operations in the context of a single transaction - allow each thread to create a sub-transaction from an initial parent transaction and then operate on its child transaction - allow a thread to specify the revision identifier of an open transaction as the state for which it opens its own transaction. i would expect to be able to do either of the first two options in an in-memory database which supports mvcc. i would expect the third option to be available in any database which supports access to revisions/versions. i would expect the first option to apply to blueprints. i would expect the third option to apply to oracle or db2 “versioning". --- james anderson | [email protected] | http://dydra.com
