-
Notifications
You must be signed in to change notification settings - Fork 5
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
Make meaning of AcquirableSessionTokens clearer #6
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -77,7 +77,10 @@ SessionTokens == [ | |
epoch: Epochs | ||
] | ||
|
||
\* The "not a session token" session token. | ||
\* The "not a session token" session token. It precedes all session tokens, | ||
\* and should be used when no session token is known / available. | ||
\* It is not a valid session token itself, but is usually compatible with them. | ||
\* | ||
\* It is not a member of SessionTokens because it has an epoch of 0, | ||
\* which is special-cased such that it is valid at all epochs. | ||
\* A read or write operation can be given this token, and that | ||
|
@@ -194,13 +197,17 @@ TypesOK == | |
/\ epoch \in Epochs | ||
/\ WriteConsistencyLevel \in ConsistencyLevels | ||
|
||
\* This operator can be used to generate a | ||
\* fresh session token. Combined with session-consistent reads and writes, | ||
\* the expectation is that one could model a client holding and progressively | ||
\* updating a session token using this operator and the ones defined near it. | ||
\* Assuming session-consistent reads and writes, | ||
\* this operator describes the set of all session tokens that could be | ||
\* acquired during the current action. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Makes sense I think - I edited that a little bit to account for both things as I understand them. |
||
\* | ||
\* Note that the range of possible checkpoints is very broad: if the newest | ||
\* write to a key is very old, the current spec will consider the returned | ||
\* token's checkpoint to point to that oldest index, even if | ||
\* the checkpoint is older than readIndex. | ||
AcquirableSessionTokens == [ | ||
epoch: {epoch}, | ||
checkpoint: readIndex..Len(log) | ||
checkpoint: 0..(Len(log) + 1) \* +1 to account for incomplete writes | ||
] | ||
|
||
\* Whether the database's current state accepts writes. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"usually"? Perhaps add, under what condition it is incompatible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe always, but I was being vague as a reflex because there may be some edge case (which would be a bug) where that isn't true. I'll just delete the word.