Closed as not planned
Closed as not planned
Description
A followup on #287
According to the RocksDB documentation, for OptimisticTransactionDB
:
commit
: will commit changes unless there is a conflict, in which case it will returnBusy
prepare
: writes to the WAL, so commit is simple, as the cost of makingrollback
more costly; it doesn't say that it would returnBusy
if there are conflicts
See:
- https://www.bookstack.cn/read/rocksdb-6.14-en/4b5d7163a69af0cb.md?wd=2nd
- https://docs.rs/rocksdb/latest/rocksdb/struct.Transaction.html#method.commit
If commit
is the one which returns Busy
then this is at odds with how STM expects it to work. Also, in STM we do the database prepare first, and the in-memory key checks second. We could do the other way around, though:
- locks the keys in the STM transaction first, detect conflicts there
- if a conflict is found, rollback the DB
- if there are no conflicts, then
try_commit
the database - if
try_commit
returnedtrue
, write to the locked in-memory places - if
try_commit
returnedfalse
, release the locks and try again