Understanding the semantics of Polly policies when separating policy definition from execution

Question

With Polly I\'d like to have my policy definition and the execution of that policy in two different statements, as in:

// Policy definition
var policy = Poli         


        

Answer 1

No concerns. Configuring policies separate from their usage, and injecting them into sites of usage, is a common pattern which we use extensively in production.

All Polly policies are thread-safe and may be used across multiple independent call-sites concurrently.

---

Two kinds of Polly policy thread-safely maintain internal state across calls, to carry out their designed functions. This leads to specific (intended) effects if you share those policy instances across call sites.

CircuitBreaker / AdvancedCircuitBreaker

The raison-d'etre is to count and act according to success/fail metrics across calls placed through the policy. Each single policy instance maintains this state for itself internally.

The (intended) functional consequence of this is that if you share a CircuitBreakerPolicy instance in multiple call sites, those multiple call sites will share circuit state, as discussed here.

• Share the same breaker policy instance across call sites when you want those call sites to break in common - for instance they have a common downstream dependency.
• Don't share a breaker instance across call sites when you want those call sites to have independent circuit state and break independently.

Bulkhead

The raison-d'etre is to limit concurrency of calls placed through it. Each single BulkheadPolicy instance maintains state internally to track that.

The (intended) functional consequence of this is that when you share a BulkheadPolicy instance across call-sites, those call-sites share the bulkhead capacity between them.

• Share the same BulkheadPolicy instance across multiple call sites when you want call sites to share the bulkhead capacity between them.
• Don't share the same BulkheadPolicy instance across multiple call sites when you want them to have independent bulkhead capacity.

No other kind of Polly policy maintains internal state in the policy instance across executions.

---

.ExecuteAndCapture(...)

The result of an .ExecuteAndCapture(...) call is not on the policy in either of the cases in the question. In both cases (definition and execution in one statement; or separated), the result of the .ExecuteAndCapture(...) call is a fresh PolicyResult instance.

Each execution returns a fresh PolicyResult instance. PolicyResult is never stored as state on a policy instance (that would make policies not thread-safe and re-useable across call sites).

Change var to the actual type (Policy or PolicyResult) in each code location, and this may be clearer to see.