2016-02-09 23:12:00 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-15 23:03:42 +00:00
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
2015-05-29 21:36:35 +00:00
|
|
|
|
|
|
|
|
2016-03-04 00:33:26 +00:00
|
|
|
#include "utilities/transactions/optimistic_transaction_db_impl.h"
|
|
|
|
|
2015-05-29 21:36:35 +00:00
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
|
2019-05-31 18:52:59 +00:00
|
|
|
#include "db/db_impl/db_impl.h"
|
2015-05-29 21:36:35 +00:00
|
|
|
#include "rocksdb/db.h"
|
|
|
|
#include "rocksdb/options.h"
|
|
|
|
#include "rocksdb/utilities/optimistic_transaction_db.h"
|
2017-08-07 23:07:40 +00:00
|
|
|
#include "utilities/transactions/optimistic_transaction.h"
|
2015-05-29 21:36:35 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2015-05-29 21:36:35 +00:00
|
|
|
|
2023-05-24 18:57:15 +00:00
|
|
|
std::shared_ptr<OccLockBuckets> MakeSharedOccLockBuckets(size_t bucket_count,
|
|
|
|
bool cache_aligned) {
|
|
|
|
if (cache_aligned) {
|
|
|
|
return std::make_shared<OccLockBucketsImpl<true>>(bucket_count);
|
|
|
|
} else {
|
|
|
|
return std::make_shared<OccLockBucketsImpl<false>>(bucket_count);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Pessimistic Transactions
Summary:
Initial implementation of Pessimistic Transactions. This diff contains the api changes discussed in D38913. This diff is pretty large, so let me know if people would prefer to meet up to discuss it.
MyRocks folks: please take a look at the API in include/rocksdb/utilities/transaction[_db].h and let me know if you have any issues.
Also, you'll notice a couple of TODOs in the implementation of RollbackToSavePoint(). After chatting with Siying, I'm going to send out a separate diff for an alternate implementation of this feature that implements the rollback inside of WriteBatch/WriteBatchWithIndex. We can then decide which route is preferable.
Next, I'm planning on doing some perf testing and then integrating this diff into MongoRocks for further testing.
Test Plan: Unit tests, db_bench parallel testing.
Reviewers: igor, rven, sdong, yhchiang, yoshinorim
Reviewed By: sdong
Subscribers: hermanlee4, maykov, spetrunia, leveldb, dhruba
Differential Revision: https://reviews.facebook.net/D40869
2015-05-26 00:37:33 +00:00
|
|
|
Transaction* OptimisticTransactionDBImpl::BeginTransaction(
|
2015-05-29 21:36:35 +00:00
|
|
|
const WriteOptions& write_options,
|
2016-03-04 00:33:26 +00:00
|
|
|
const OptimisticTransactionOptions& txn_options, Transaction* old_txn) {
|
|
|
|
if (old_txn != nullptr) {
|
|
|
|
ReinitializeTransaction(old_txn, write_options, txn_options);
|
|
|
|
return old_txn;
|
|
|
|
} else {
|
2017-08-07 23:07:40 +00:00
|
|
|
return new OptimisticTransaction(this, write_options, txn_options);
|
2016-03-04 00:33:26 +00:00
|
|
|
}
|
2015-05-29 21:36:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Status OptimisticTransactionDB::Open(const Options& options,
|
|
|
|
const std::string& dbname,
|
|
|
|
OptimisticTransactionDB** dbptr) {
|
|
|
|
DBOptions db_options(options);
|
|
|
|
ColumnFamilyOptions cf_options(options);
|
|
|
|
std::vector<ColumnFamilyDescriptor> column_families;
|
2024-03-04 18:08:32 +00:00
|
|
|
column_families.emplace_back(kDefaultColumnFamilyName, cf_options);
|
2015-05-29 21:36:35 +00:00
|
|
|
std::vector<ColumnFamilyHandle*> handles;
|
|
|
|
Status s = Open(db_options, dbname, column_families, &handles, dbptr);
|
|
|
|
if (s.ok()) {
|
|
|
|
assert(handles.size() == 1);
|
|
|
|
// i can delete the handle since DBImpl is always holding a reference to
|
|
|
|
// default column family
|
|
|
|
delete handles[0];
|
|
|
|
}
|
|
|
|
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status OptimisticTransactionDB::Open(
|
|
|
|
const DBOptions& db_options, const std::string& dbname,
|
|
|
|
const std::vector<ColumnFamilyDescriptor>& column_families,
|
|
|
|
std::vector<ColumnFamilyHandle*>* handles,
|
|
|
|
OptimisticTransactionDB** dbptr) {
|
2020-01-07 22:19:06 +00:00
|
|
|
return OptimisticTransactionDB::Open(db_options,
|
|
|
|
OptimisticTransactionDBOptions(), dbname,
|
|
|
|
column_families, handles, dbptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status OptimisticTransactionDB::Open(
|
|
|
|
const DBOptions& db_options,
|
|
|
|
const OptimisticTransactionDBOptions& occ_options,
|
|
|
|
const std::string& dbname,
|
|
|
|
const std::vector<ColumnFamilyDescriptor>& column_families,
|
|
|
|
std::vector<ColumnFamilyHandle*>* handles,
|
|
|
|
OptimisticTransactionDB** dbptr) {
|
2015-05-29 21:36:35 +00:00
|
|
|
Status s;
|
|
|
|
DB* db;
|
|
|
|
|
|
|
|
std::vector<ColumnFamilyDescriptor> column_families_copy = column_families;
|
|
|
|
|
|
|
|
// Enable MemTable History if not already enabled
|
|
|
|
for (auto& column_family : column_families_copy) {
|
|
|
|
ColumnFamilyOptions* options = &column_family.options;
|
|
|
|
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 20:54:09 +00:00
|
|
|
if (options->max_write_buffer_size_to_maintain == 0 &&
|
|
|
|
options->max_write_buffer_number_to_maintain == 0) {
|
|
|
|
// Setting to -1 will set the History size to
|
|
|
|
// max_write_buffer_number * write_buffer_size.
|
|
|
|
options->max_write_buffer_size_to_maintain = -1;
|
2015-05-29 21:36:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
s = DB::Open(db_options, dbname, column_families_copy, handles, &db);
|
|
|
|
|
|
|
|
if (s.ok()) {
|
2020-01-07 22:19:06 +00:00
|
|
|
*dbptr = new OptimisticTransactionDBImpl(db, occ_options);
|
2015-05-29 21:36:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2016-03-04 00:33:26 +00:00
|
|
|
void OptimisticTransactionDBImpl::ReinitializeTransaction(
|
|
|
|
Transaction* txn, const WriteOptions& write_options,
|
|
|
|
const OptimisticTransactionOptions& txn_options) {
|
2017-08-07 23:07:40 +00:00
|
|
|
assert(dynamic_cast<OptimisticTransaction*>(txn) != nullptr);
|
Prefer static_cast in place of most reinterpret_cast (#12308)
Summary:
The following are risks associated with pointer-to-pointer reinterpret_cast:
* Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do.
* Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally.
I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement:
* Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have
`struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic.
* Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance.
With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain.
A couple of related interventions included here:
* Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle.
* Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse).
Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work.
I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308
Test Plan: existing tests, CI
Reviewed By: ltamasi
Differential Revision: D53204947
Pulled By: pdillinger
fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
|
|
|
auto txn_impl = static_cast<OptimisticTransaction*>(txn);
|
2016-03-04 00:33:26 +00:00
|
|
|
|
|
|
|
txn_impl->Reinitialize(this, write_options, txn_options);
|
|
|
|
}
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|