KVSLockAcquired¶

from Shards

Purpose¶

This message informs the Worker Engine that the sending Shard has recorded upcoming read or write requests to a key specified in an earlier KVSAcquireLock from the Worker Engine. It is an asynchronous response.

Structure¶

Field	Type	Description
`fingerprint`	TxFingerprint	the fingerprint of the TransactionCandidate for which some locks have been recorded
`key`	KVSKey	the key in the key value store that will be accessed
`write`	`bool`	`true` for write, `false` for read
`optional`	`bool`	`true` for may_write or may_read, `false` for will_write or will_read

Effects¶

The Worker Engine adds this lock to a store of lock acquisitions that have been recorded by the shards such that it may be able to send UpdateSeenAll messages with greater TxFingerprints than the last one sent.
Once an UpdateSeenAll message is sent, all information the Worker Engine stores concerning KVSLockAcquired-message for earlier transactions can be freed.

Triggers¶

to Shards: UpdateSeenAll if we can now be certain that there is some new TxFingerprint T, after (the last one) of the previously sent UpdateSeenAll, such that no more KVSAcquireLock-messages featuring timestamps at or before T will be sent by the same Worker Engine: then send UpdateSeenAll with T to all Shards.

Note¶

Otherwise, a Shard might hear about a KVSAcquireLock only after it has heard UpdateSeenAll with a later TxFingerprint, causing it to execute the "later" transaction before it learned of the "earlier" one, which could allow the "later" transaction to read the wrong value from state. Therefore, it is important to let Worker Engines know which KVSAcquireLocks the shard has received.

(Wiki) links on this page

In this way, a lock may be granted without knowing about declared access that would have to be served before. ↩