ExecuteTransaction¶

from Mempool

Purpose¶

The mempool engines instruct the Executor that a new TransactionCandidate has been recorded, its locks are being acquired, and will eventually need to be executed.

Structure¶

Field	Type	Description
`executable`	TransactionExecutable	"code" to be executed post-ordering
`label`	TransactionLabel	information about keys that the transaction can rightfully access
`timestamp`	TxFingerprint	(partial) ordering information (sufficient for V1)
`curator`	ExternalIdentity	the Worker Engine to be informed when execution completes (e.g. for logs)
`issuer`	ExternalIdentity	the ID of the sender of the TransactionRequest

Effects¶

This message is sent to an Executor that is already running. Concurrently, when the Worker Engine sends a KVSAcquireLock to Shards, they can include eager reads, which will result in KVSReads sent to this Executor.

Triggers¶

{KVSReadRequest, KVSWrite}→Shards: In the course of evaluating the executor function, lazy reads are requested, and final writes are output.
KVSReadRequest to Shard
KVSWrite to Shard

Todo

make this precise :-/

Notes¶

Getting served read requests amounts to locks being granted by the shards.

Todo

contention footprint description

(Wiki) links on this page