Home → Documentation → Runtime → Execution
Every request follows the same execution pipeline.
Immutable Plan
↓
Execution Context
↓
SQL Generation
↓
Database Execution
↓
Materialization
↓
Return Result
The Runtime coordinates each stage but delegates specialized work to other layers.
The execution context carries request-scoped state.
Typical contents include:
Execution contexts should remain lightweight.
Mutations frequently depend on previously generated values.
Example:
Customer
↓
CustomerAddress
↓
CustomerOrder
The planner computes dependency ordering.
Runtime executes operations in dependency order.
No dependency analysis occurs during execution.
Runtime coordinates generated materializers.
DbDataReader
↓
Generated Materializer
↓
CLR Object
Runtime does not inspect CLR properties.
Generated code performs object construction.
Runtime coordinates transaction boundaries.
Typical workflow:
Begin Transaction
↓
Execute Plan
↓
Commit
↓
Return Result
Failures result in rollback.
Transaction policy remains transport-independent.
Runtime reports execution failures through well-defined exception types.
Typical categories include:
Transport layers translate these exceptions into protocol-specific responses.
Runtime services should generally be stateless.
Immutable metadata and immutable execution plans naturally support concurrent execution.
Mutable state should remain confined to execution contexts.
| ← Previous: Runtime | Next: Queries → |