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