Concurrent writes, kv vs tx

[JesusTheHun]

@mreiche

@JesusTheHun

It does not elaborate further on how this can happen

It can happen any time a write is done without using transactions. So if you have an existing application that does not use transactions, or someone using the WebUI that is updating the same document - those could result in concurrent updates even though you are using transactions elsewhere.

Of course, but I’m interested in concurrent writes with non-tx vs tx, specifically.

@mreiche

@JesusTheHun

and what is an effective way to prevent this (2)

Don’t do it. Perhaps by always using transactions.

I thought about that, but it is impractical.

@mreiche

how to handle concurrent writes.

relying on the CAS to detect concurrent modifications is faster and eaiser. Unless you have something that specifically requires transactions - such as modifications to multiple documents - I would recommend just using the CAS mechanism.

Yes, but again, I’m interested specifically in transactions.

@mreiche

O.1) block until the doc has been read inside the tx.
I.1) start the transaction
I.2) read the document, unblock O
I.3) block until the doc has been read outside the tx.
O.2) read and update the document
O.3) unblock I
I.4) update the document in the transaction
I.5) complete the transaction

The transaction will succeed (without complaining about the concurrent update from O.2) and the update from O.2 will have been overwritten.

I’ve already tried that exact sequence.
The result is : the tx throws and the document content is the one from O.
Which makes sense, because the tx uses the cas, so the replace fails.

I think it’s more likely that an overwrite happens during the unstaging phase.
The unstaging probably doesn’t check for cas when swapping the content from xattr to the document body. The tx cannot be rollback at this point anyway, so checking for the cas would be quite irrelevant. WDYT ?