james anderson wrote:
> On 2020-12-03, at 23:40:18, Howard Chu <hyc(a)symas.com> wrote:
>
> james anderson wrote:
>>
>>> On 2020-12-03, at 19:17:46, Howard Chu <hyc(a)symas.com> wrote:
>>>
>>> Gábor Melis wrote:
>>>> On Wed, 2 Dec 2020 at 22:50, james anderson
>>>> <anderson.james.1955(a)gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On 2020-12-02, at 22:53:58, Howard Chu <hyc(a)symas.com>
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 | james(a)dydra.com |
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/