Merge bitcoin/bitcoin#29112: sqlite: Disallow writing from multiple SQLiteBatchs

cfcb9b1ecf test: wallet, coverage for concurrent db transactions (furszy)
548ecd1155 tests: Test for concurrent writes with db tx (Ava Chow)
395bcd2454 sqlite: Ensure that only one SQLiteBatch is writing to db at a time (Ava Chow)

Pull request description:

  The way that we have configured SQLite to run means that only one database transaction can be open at a time. Typically, each individual read and write operation will be its own transaction that is opened and committed automatically by SQLite. However, sometimes we want these operations to be batched into a multi-statement transaction, so `SQLiteBatch::TxnBegin`, `SQLiteBatch::TxnCommit`, and `SQLiteBatch::TxnAbort` are used to manage the transaction of the database.

  However, once a db transaction is begun with one `SQLiteBatch`, any operations performed by another `SQLiteBatch` will also occur within the same transaction. Furthermore, those other `SQLiteBatch`s will not be expecting a transaction to be active, and will abort it once the `SQLiteBatch` is destructed. This is problematic as it will prevent some data from being written, and also cause the `SQLiteBatch` that opened the transaction in the first place to be in an unexpected state and throw an error.

  To avoid this situation, we need to prevent the multiple batches from writing at the same time. To do so, I've implemented added a `CSemaphore` within `SQLiteDatabase` which will be used by any `SQLiteBatch` trying to do a write operation. `wait()` is called by `TxnBegin`, and at the beginning of `WriteKey`, `EraseKey`, and `ErasePrefix`. `post()` is called in `TxnCommit`, `TxnAbort` and at the end of `WriteKey`, `EraseKey`, and `ErasePrefix`. To avoid deadlocking on ` TxnBegin()` followed by a `WriteKey()`, `SQLiteBatch will now also track whether a transaction is in progress so that it knows whether to use the semaphore.

  This issue is not a problem for BDB wallets since BDB uses WAL and provides transaction objects that must be used if an operation is to occur within a transaction. Specifically, we either pass a transaction pointer, or a nullptr, to all BDB operations, and this allows for concurrent transactions so it doesn't have this problem.

  Fixes #29110

ACKs for top commit:
  josibake:
    ACK https://github.com/bitcoin/bitcoin/pull/29112/commits/cfcb9b1ecf9be5267487713fa1e112ca09a1ae55
  furszy:
    ACK cfcb9b1ecf
  ryanofsky:
    Code review ACK cfcb9b1ecf. This looks great and I think it is ready for merge. Just holding off because josibake seemed ready to review https://github.com/bitcoin/bitcoin/pull/29112#issuecomment-1930372190 and might have more feedback.

Tree-SHA512: 2dd5a8e76df52451a40e0b8a87c7139d68a0d8e1bf2ebc79168cc313e192dab87cfa4270ff17fea4f7b370060d3bc9b5d294d50f7e07994d9b5a69b40397c927
This commit is contained in:
Ryan Ofsky committed 2024-02-07 21:46:06 -05:00
commit 801ef07ebd
4 files changed
+129 -6

No files matched your search

+41 -1
View File
@@ -279,8 +279,48 @@ BOOST_AUTO_TEST_CASE(txn_close_failure_dangling_txn)
BOOST_CHECK(!batch2->Exists(key));
}
#endif // USE_SQLITE
BOOST_AUTO_TEST_CASE(concurrent_txn_dont_interfere)
{
std::string key = "key";
std::string value = "value";
std::string value2 = "value_2";
DatabaseOptions options;
DatabaseStatus status;
bilingual_str error;
const auto& database = MakeSQLiteDatabase(m_path_root / "sqlite", options, status, error);
std::unique_ptr<DatabaseBatch> handler = Assert(database)->MakeBatch();
// Verify concurrent db transactions does not interfere between each other.
// Start db txn, write key and check the key does exist within the db txn.
BOOST_CHECK(handler->TxnBegin());
BOOST_CHECK(handler->Write(key, value));
BOOST_CHECK(handler->Exists(key));
// But, the same key, does not exist in another handler
std::unique_ptr<DatabaseBatch> handler2 = Assert(database)->MakeBatch();
BOOST_CHECK(handler2->Exists(key));
// Attempt to commit the handler txn calling the handler2 methods.
// Which, must not be possible.
BOOST_CHECK(!handler2->TxnCommit());
BOOST_CHECK(!handler2->TxnAbort());
// Only the first handler can commit the changes.
BOOST_CHECK(handler->TxnCommit());
// And, once commit is completed, handler2 can read the record
std::string read_value;
BOOST_CHECK(handler2->Read(key, read_value));
BOOST_CHECK_EQUAL(read_value, value);
// Also, once txn is committed, single write statements are re-enabled.
// Which means that handler2 can read the record changes directly.
BOOST_CHECK(handler->Write(key, value2, /*fOverwrite=*/true));
BOOST_CHECK(handler2->Read(key, read_value));
BOOST_CHECK_EQUAL(read_value, value2);
}
#endif // USE_SQLITE
BOOST_AUTO_TEST_SUITE_END()
} // namespace wallet