foundationdb

Module budget

Source
Expand description

Per-attempt usage accounting and the client-side budget.

The budget is a client-side feature of this Rust binding, not a native FoundationDB limit. Nothing here is enforced by the cluster: the binding counts the bytes and calls that go through Transaction and compares them with the configured limits when you ask it to, with Transaction::check_client_budget. The numbers are therefore an estimate, checked between operations: a single operation can overshoot a limit, and reads that are still in flight are not counted yet.

It is fully decoupled from TransactionOption::Timeout and TransactionOption::SizeLimit, which are enforced by the C client. Use those to bound what the database does; use the budget to bound what your own code does before it reaches them.

§Per-attempt semantics

Accounting is always on and scoped to a single transaction attempt: usage is reset whenever the transaction restarts (on_error, reset), while the configured limits survive and apply to the new attempt. A retried transaction therefore gets a fresh time and byte allowance, exactly like it gets a fresh read version.

§Determinism and simulation

The byte and call counters are deterministic: they depend only on the operations your code issues. ClientBudget::time_limit is not, unless you say where time comes from: give the budget a Clock with ClientBudget::with_clock and every elapsed time of the attempt is measured with it. Under FoundationDB’s deterministic simulator, pass a clock backed by simulated time so that a run replays identically.

Without one the WallClock is used, which is the right default outside simulation but makes time budgets non-reproducible: do not rely on them in a simulated workload. See crate::env for the whole picture.

Structs§

Enums§