mirror of https://github.com/facebook/rocksdb.git
c9042db619
Summary: Range Locking supports Lock Escalation. Lock Escalation is invoked when lock memory is nearly exhausted and it reduced the amount of memory used by joining adjacent locks. Bridging the gap between certain locks has adverse effects. For example, in MyRocks it is not a good idea to bridge the gap between locks in different indexes, as that get the lock to cover large portions of indexes, or even entire indexes. Resolve this by introducing Escalation Barrier. The escalation process will call the user-provided barrier callback function: bool(const Endpoint& a, const Endpoint& b) If the function returns true, there's a barrier between a and b and Lock Escalation will not try to bridge the gap between a and b. Pull Request resolved: https://github.com/facebook/rocksdb/pull/9290 Reviewed By: akankshamahajan15 Differential Revision: D33486753 Pulled By: riversand963 fbshipit-source-id: f97910b67aba0579ea1d35f523ca6863d3dd018e |
||
|---|---|---|
| .. | ||
| lock | ||
| optimistic_transaction.cc | ||
| optimistic_transaction.h | ||
| optimistic_transaction_db_impl.cc | ||
| optimistic_transaction_db_impl.h | ||
| optimistic_transaction_test.cc | ||
| pessimistic_transaction.cc | ||
| pessimistic_transaction.h | ||
| pessimistic_transaction_db.cc | ||
| pessimistic_transaction_db.h | ||
| snapshot_checker.cc | ||
| transaction_base.cc | ||
| transaction_base.h | ||
| transaction_db_mutex_impl.cc | ||
| transaction_db_mutex_impl.h | ||
| transaction_test.cc | ||
| transaction_test.h | ||
| transaction_util.cc | ||
| transaction_util.h | ||
| write_prepared_transaction_test.cc | ||
| write_prepared_txn.cc | ||
| write_prepared_txn.h | ||
| write_prepared_txn_db.cc | ||
| write_prepared_txn_db.h | ||
| write_unprepared_transaction_test.cc | ||
| write_unprepared_txn.cc | ||
| write_unprepared_txn.h | ||
| write_unprepared_txn_db.cc | ||
| write_unprepared_txn_db.h | ||