facebook / facebook/rocksdb

race condition in OptimisticTransaction::CommitWithParallelValidate

Open
#10,663 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
32.1k
Forks
6.9k
Avg merge
32m
Merged PRs (30d)
1

Description

> Note: Please use Issues only for bug reports. For questions, discussions, feature requests, etc. post to dev group: https://groups.google.com/forum/#!forum/rocksdb or https://www.facebook.com/groups/rocksdb.dev

### Expected behavior
OptimisticTransaction::CommitWithParallelValidate() actually prevent race between TransactionUtil::CheckKeysForConflicts() and DBImpl::Write(), as implied by [its example code](https://github.com/facebook/rocksdb/blob/v7.5.3/examples/optimistic_transaction_example.cc#L117)

### Actual behavior
OptimisticTransaction::CommitWithParallelValidate() cannot prevect race between TransactionUtil::CheckKeysForConflicts() and DBImpl::Write()

### Steps to reproduce the behavior
Read the source code, sepcifically between [calling TransactionUtil::CheckKeysForConflicts](https://github.com/facebook/rocksdb/blob/v7.5.3/utilities/transactions/optimistic_transaction.cc#L123) and [calling DBImpl::Write()](https://github.com/facebook/rocksdb/blob/v7.5.3/utilities/transactions/optimistic_transaction.cc#L129)

The moment thread T1 has just done executing L123, another thread T2 write something into db, then T1 executes L129, the transaction will falsely commit, contrary to what is implied by the [occ example code](https://github.com/facebook/rocksdb/blob/v7.5.3/examples/optimistic_transaction_example.cc#L117)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.