Bedrock.ControlPlane.Config.TransactionSystemLayout (bedrock v0.7.0)
View SourceA TransactionSystemLayout is a data structure that describes the layout of
the transaction system within the cluster.
Summary
Types
The transaction system's runtime wiring, published once per recovery -
FDB's ClientDBInfo/ServerDBInfo analogue. Shard topology deliberately
does NOT ride here: the shard map lives in the \xFF/system keyspace
and is served to clients by commit proxies (bedrock-q67.9).
Types
@type log_map() :: %{ required(Bedrock.DataPlane.Log.id()) => Bedrock.ControlPlane.Config.LogDescriptor.t() }
@type process_ref() :: pid() | nil
The transaction system's runtime wiring, published once per recovery -
FDB's ClientDBInfo/ServerDBInfo analogue. Shard topology deliberately
does NOT ride here: the shard map lives in the \xFF/system keyspace
and is served to clients by commit proxies (bedrock-q67.9).
Fields
epoch- The recovery epoch this wiring belongs to.sequencer- The pid of the cluster sequencer (read versions).proxies- The pids of the commit proxies (commits, routing fetches).resolvers- Resolver descriptors, consumed at proxy unlock.logs- Log descriptors: each log's id and the tags it services.
No membership map rides here (FDB's ServerDBInfo carries no storage membership either): logs self-check against the epoch-constant log set, materializers rejoin-validate against the committed keyspace through a commit proxy, and director-internal readers consume the recovery attempt's transaction_services. Nothing O(workers) may ever be added to this broadcast.
@type proxy_list() :: [pid()]
@type resolver_list() :: [Bedrock.ControlPlane.Config.ResolverDescriptor.t()]
@type t() :: %{ epoch: non_neg_integer(), sequencer: process_ref(), proxies: proxy_list(), resolvers: resolver_list(), logs: log_map() }