james anderson wrote: > >> 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
No. A transaction is a single unit for concurrency control. Allowing multiple threads to operate within a single transaction means you have no control, and thus invites memory corruption. No transaction system in existence supports this. > - allow each thread to create a sub-transaction from an initial parent > transaction and then operate on its child transaction Same as above. The docs on child transactions are quite clear - when a child transaction is active, the parent transaction cannot be used again until the child finishes. > - 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-mery > database which supports mvcc. Clearly that would be a broken design. > i would expect the third option to be available in any database which > supports access to revisions/versions. That is not what LMDB does. Please read the LMDB design spec. https://openldap.org/pub/ > 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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
