node: main chain db txn management #2112
Conversation
…om/erigontech/silkworm into execution_engine_integration_tests
canepat
changed the title
| //! @brief Handles the transaction lifecycle for long-standing and per-request transactions | ||
| class TransactionHandler { | ||
| public: | ||
| TransactionHandler(silkworm::db::RWTxnManaged& txn, silkworm::db::RWAccess& db_access, bool keep_db_txn_open = true) |
There was a problem hiding this comment.
We typically use db::RWTxnManaged only when we need to ensure proper ownership of txn lifecycle (e.g. in stagedsync::MainChain which holds its own txn), otherwise it is sufficient to use just db::RWTxn, passed by reference.
This approach follows the same convention used by MDBX API, which contains different abstractions for managed classes (e.g. ::mdbx::env_managed, ::mdbx::txn_managed...) and unmanaged ones (e.g. ::mdbx::env, ::mdbx::txn...). The latter ones are handles wrapping up a raw pointer and have nice pass-by-value-and-move semantics.
|
|
||
| private: | ||
| silkworm::db::RWTxnManaged& txn_; | ||
| silkworm::db::RWAccess& db_access_; |
There was a problem hiding this comment.
db::ROAccess and db::RWAccess are lightweight wrappers for ::mdbx::env used to enforce strict usage of read-only vs read-write transactions. ::mdbx::env is in turn just a handle wrapping a raw pointer, so all of them are a perfect fit for pass by-value and move.
This PR prepares
MainChainfor silkworm-go integration with Erigon. Erigon requires transaction-per-request, contrary to Silkworm where we use a single transaction.Another tiny change is that
MainChain::close()commits the data rather than aborting it. The reason is thatinsert_blocks()in the long-standing transaction mode, only commits the data every 1k blocks. So if you callclose()before, you could lose valid data.