Skip to content

KVSAcquireLock

Purpose

Inform the shard about keys that a transaction may/will read and/or write, at a transaction fingerprint.

Structure

Field Type Description
lazy_read_keys KVSKey set Keys this transaction may read (only send values read in response to KVSReadRequests)
eager_read_keys KVSKey set Keys this transaction will read (send values read as soon as possible)
will_write_keys KVSKey set Keys this transaction will write. Future reads are dependent only on the KVSWrite for this TxFingerprint.
may_write_keys KVSKey set Keys this transaction may write. Future reads are dependent on the KVSWrite for this TxFingerprint, or, if that has a None, the previous value.
curator ExternalIdentity the Worker Engine in charge of the corresponding transactions
executor ExternalIdentity the Executor for this TransactionCandidate
timestamp TxFingerprint specifies the transaction affiliated with these locks.

The lazy_read_keys and eager_read_keys may not overlap. In the same way, will_write_keys and may_write_keys must be disjoint. There must be one KVSAcquireLock per Shard per TxFingerprint: for a given Shard and TxFingerprint, all information is to be provided in totality or not at all.1

Note that future versions may use some kind of structured Keys to encode "Sets" containing infinitely many Keys. For V1, however, simple HashSets or similar are fine.

Effects

  • The Shard stores the respective "locks" for all keys in its timeline.
    • these are the "markers" described in Shard State.
  • The eager_read_keys will be served as soon as possible (by sending KVSRead-messages to the executor).
  • The Shard immediately informs the curator that the locks are acquired, using a KVSLockAcquired message, so the curator can prepare UpdateSeenAll messages.

Triggers

(Wiki) links on this page

  1. Note that transaction requests come with all this information at once for each transaction candidate. ↩