Skip to main content
OptimisticTransactionDB provides optimistic concurrency control without locking during transaction execution. Conflicts are detected at commit time, making it ideal for workloads with low contention.

Opening an OptimisticTransactionDB

Open

Opens an OptimisticTransactionDB similar to DB::Open().
const Options&
Database options.
const OptimisticTransactionDBOptions&
Options specific to optimistic concurrency control.
const std::string&
Path to the database directory.
OptimisticTransactionDB**
Output parameter for the opened database instance.
Status
Returns OK on success, or an error status if the database cannot be opened.

Transaction Management

BeginTransaction

Starts a new optimistic transaction.
const WriteOptions&
Write options for the transaction.
const OptimisticTransactionOptions&
Transaction-specific options.
Transaction*
Optional transaction handle to reuse.
Transaction*
Returns a pointer to the new transaction. Caller is responsible for deletion.

Options and Configuration

OptimisticTransactionOptions

bool
Whether to automatically set a snapshot at transaction start.
const Comparator*
Comparator for the WriteBatchWithIndex. Should match the DB comparator.

OptimisticTransactionDBOptions

OccValidationPolicy
Validation strategy: kValidateSerial (in write-group) or kValidateParallel (before write-group).
uint32_t
Number of striped mutex locks for parallel validation. Larger values reduce contention but use more memory.
std::shared_ptr<OccLockBuckets>
Shared pool of mutex locks that can be shared among multiple databases.

Validation Policies

kValidateSerial

Validates serially at commit stage after entering the write-group. Single-threaded validation may suffer from mutex contention under high load.

kValidateParallel

Validates in parallel before entering the write-group. Each transaction acquires locks for its write-set in a well-defined order, reducing mutex contention.

Example

Key Differences from TransactionDB

No Locking During Execution

OptimisticTransactionDB does not acquire locks during transaction execution. This provides better performance for read-heavy workloads and scenarios with low contention.

Conflict Detection at Commit

Conflicts are detected when Commit() is called. If another transaction modified the same keys, Commit() returns Status::Busy() and the transaction must be retried.

Better Concurrency

Without locking, optimistic transactions can achieve higher concurrency, especially for read-heavy workloads.

Lower Overhead

No lock management overhead makes optimistic transactions lighter weight than pessimistic transactions.

Limitations

Range Deletions Not Supported

Range deletions (including those in WriteBatch) are incompatible with OptimisticTransactionDB and will return a non-OK Status.

Higher Abort Rate Under Contention

With high write contention, the transaction abort rate can be high, requiring more retries.

See Also