Gábor Melis wrote:
On Wed, 2 Dec 2020 at 22:50, james anderson
>> 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
>>> 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/