https://bugs.openldap.org/show_bug.cgi?id=10395
--- Comment #2 from kero <[email protected]> --- > I don't see intentionally breaking ACID as being a good idea. Reading > uncommitted changes breaks Atomicity and Isolation at least, and may break > Consistency in various situations. I may have been unclear about the changes I made, or I may have made an error in the code. The nested transactions do the same as the write transaction: they _read their own writes_. It is already supported. The only difference is that you can _read your writes_ in parallel, now. Additionally, the parent write transaction is unusable and only an abort can be performed, and only after the nested transactions are aborted. If it's not the case, I need to implement that as we mentioned in this Mastodon thread [1]. The goal of this feature is not related to parallel writes, but rather to allow parallel reads on uncommitted changes *from within the write transaction*. Nothing can go outside. To write into the write transaction, you have to abort the many nested read-only transactions and use the original parent transaction. You must store data somewhere (RAM, disk) before being able to write to LMDB. I don't want to break ACID, here. > The only thing that ought to be able to see uncommitted changes is the active > write transaction. If anything else does, then you don't have a transactional > DB engine any more. In ACID operation "newly inserted or modified document > IDs" *don't exist* until their transaction commits. Currently, IIRC, nested transactions can see uncommitted changes as well, as can the outer transaction. This PR proposes to do the same, but from multiple read-only transactions that are hooked to the parent transaction. You can only have one write-active nested transaction, and in the case of this very feature, there is not even the possibility to write while the nested read-only transactions are active. > Using multiple reader txns is the correct approach. When the writer commits, > you can simply txn_reset() all the readers to get them all on the latest data. That's the issue we have with Meilisearch: we would like to be able to read uncommitted changes to avoid desync issues, and in parallel, to do it quickly and scale with the number of CPUs. [1]: https://fosstodon.org/@kero/113465979956049984 -- You are receiving this mail because: You are on the CC list for the issue.
