Conversation
Contributor
Author
|
Merging also merges #3868 |
Centril
approved these changes
Dec 15, 2025
Contributor
Centril
left a comment
Centril
left a comment
There was a problem hiding this comment.
Looks good, just some minor stuff.
Shubham8287
reviewed
Dec 15, 2025
KirstenWF
pushed a commit
to KirstenWF/SpacetimeDB
that referenced
this pull request
Dec 17, 2025
Controlled shutdown of a database should drain the outstanding transactions queue(s) and flush them to the durability layer. With the introduction of another queueing layer in clockworklabs#3868, it became harder to observe when or if this process is completed. This patch thus introduces an explicit (async) shutdown method for `RelationalDB` and below, which will wait until all submitted transactions are either reported durable, or an error occurs in the durability layer. `RelationalDB` is made `!Clone`, such that shutdown can be initiated in the `Drop` impl. Note that this requires access to a tokio runtime, which we thread through via the `Persistence` services in order to allow control over which of the various runtimes is being used for durability-related tasks. Also moves `RelationalDB::open` to a blocking thread when a persistence-enabled database is constructed by the `HostController` -- this process performs heavy I/O and can take a substantial amount of time, during which we don't want to block a worker thread. # API and ABI breaking changes None # Expected complexity level and risk 3 # Testing - [ ] some testing added - [ ] existing tests still pass - [ ] `impl Drop for RelationalDB` difficult to test, extra eyeballs needed --------- Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Controlled shutdown of a database should drain the outstanding transactions
queue(s) and flush them to the durability layer.
With the introduction of another queueing layer in #3868, it became harder to
observe when or if this process is completed.
This patch thus introduces an explicit (async) shutdown method for
RelationalDBand below, which will wait until all submitted transactions areeither reported durable, or an error occurs in the durability layer.
RelationalDBis made!Clone, such that shutdown can be initiated in theDropimpl. Note that this requires access to a tokio runtime, which we threadthrough via the
Persistenceservices in order to allow control over which ofthe various runtimes is being used for durability-related tasks.
Also moves
RelationalDB::opento a blocking thread when a persistence-enableddatabase is constructed by the
HostController-- this process performs heavyI/O and can take a substantial amount of time, during which we don't want to
block a worker thread.
API and ABI breaking changes
None
Expected complexity level and risk
3
Testing
impl Drop for RelationalDBdifficult to test, extra eyeballs needed