Skip to content

Clarify persistence order requirements for async persistence #3951

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 15 additions & 4 deletions lightning/src/util/persist.rs
Original file line number Diff line number Diff line change
Expand Up @@ -215,10 +215,21 @@ pub trait KVStore {
fn read(
&self, primary_namespace: &str, secondary_namespace: &str, key: &str,
) -> Pin<Box<dyn Future<Output = Result<Vec<u8>, io::Error>> + 'static + Send>>;
/// Persists the given data under the given `key`. Note that the order of multiple writes calls needs to be retained
/// when persisting asynchronously. One possible way to accomplish this is by assigning a version number to each
/// write before returning the future, and then during asynchronous execution, ensuring that the writes are executed in
/// the correct order.
/// Persists the given data under the given `key`.
///
/// The order of multiple writes to the same key needs to be retained while persisting
/// asynchronously. In other words, if two writes to the same key occur, the state (as seen by
/// [`Self::read`]) must either see the first write then the second, or only ever the second,
/// no matter when the futures complete (and must always contain the second write once the
/// second future completes). The state should never contain the first write after the second
/// write's future completes, nor should it contain the second write, then contain the first
/// write at any point thereafter (even if the second write's future hasn't yet completed).
///
/// One way to ensure this requirement is met is by assigning a version number to each write
/// before returning the future, and then during asynchronous execution, ensuring that the
/// writes are executed in the correct order.
///
/// Note that no ordering requirements exist for writes to different keys.
///
/// Will create the given `primary_namespace` and `secondary_namespace` if not already present in the store.
fn write(
Expand Down
Loading