KVSWrite¶
- from Executor
Purpose¶
Informs the Shard about a new write request, which happens in either of the following two cases:
- A TransactionExecutable has determined that it actually will write the value at some key for which it has a write (in its TransactionLabel). Now the Executor is requesting that value from the Shard that stores it.
- A TransactionExecutable has finished, and does not actually need to write a value for some key for which it has a lazy write (a may_write in the TransactionLabel).
Structure¶
| Field | Type | Description |
|---|---|---|
timestamp |
TxFingerprint | the logical time at which we are writing this data. |
key |
KVSKey | the key used. With fancy hierarchical keys or suchlike, we could even specify a range of keys |
datum |
KVSDatum option | the new data to be associated with the key. No datum should only be used in a "may_write," and means don't change this value |
Effects¶
A Shard should delay processing a KVSWrite until it has completed processing KVSAcquireLock for the same timestamp.
If the datum is None, then remove the may write marker from
this timestamp in state.
Any reads waiting to read what is written here must instead read from
the previous write.
- One way to accomplish this is to copy the previous write as a
"value written" at this timestamp in state.
If datum is occupied, then remove the may write or will write
marker from this timestamp in state, and record the
value written at this timestamp in state.
This may trigger a KVSRead if there are any will read markers for which this timestamp is the unique previous write.
Triggers¶
- to Executor: KVSRead
for eachwill read lock dependent on this write: send a KVSRead to the relevant Executor with the value written.