-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Description
I am running some experiments on a personal fork of RocksDB and am interested in a variant of optimistic transactions that disables all conflict checking between concurrent transactions. My understanding is that, by default, RocksDB will, upon commit of an optimistic transaction T, check that no other transaction concurrently wrote to a key that T wrote to. As I understand it, this conflict checking currently occurs in this code.
I am curious whether it is straightforward to simply disable this checking by ignoring the status codes returned on conflict in that code block, to give a variant of transactions that never aborts a transaction on concurrent write conflicts. I have already explored this in a prototype and things seem to run OK. Mainly, I am curious whether there are any other parts of the concurrency control code that may implicitly rely on the assumption that no two concurrent transactions write to the same keys and successfully commit.
Any thoughts or insights would be appreciated.