On 2020-12-04, at 14:51:42, Howard Chu <hyc(a)symas.com> wrote:
james anderson wrote:
>
>> On 2020-12-04, at 03:07:19, Howard Chu <hyc(a)symas.com> wrote:
>>
>> 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
>>>>>>>
>>>>>>> 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.
>
> you note in your paper on lmdb that, “because of [mvcc] isolation read accesses ...
always have a self-consistent view of the database."
> how are operations performed by threads within a transaction to corrupt this view
when their access is through read-only memory and they do nothing to change it?
You assume that the read-only on-disk state is the only state maintained within
a transaction structure, which is not necessarily true.
no, i did not.
i asked.
Anyway, it's not your
place to make any assumptions about the internal state of the library beyond
what the API docs guarantee.
Relying on internal implementation details like that is how you write broken software.
all true, but, your question was
"How would you do this in any other database system?"
in any case, the central question in this thread was
“[how to] guarantee that [a number of autonomous threads] operate on the same database
state?”
where “operate” was limited to read operations.
your response suggests that one should not expect to be able to do this with the current
lmdb api.
have i understood you correctly?
---
james anderson | james(a)dydra.com |
http://dydra.com