Servlet‑Loop vs. Servlet‑Per‑Request: Preventing Duplicate Writes on Retry

Background

The Racket web-server/servlet module offers two modes of request handling: servlet-loop and servlet-per-request. A retry mechanism that re‑invokes the handler can unintentionally duplicate state changes such as writes to a database or file.

Unresolved Decision

When a servlet encounters a transient failure, should the retry logic be embedded inside the handler (risking duplicate writes with servlet-loop) or should an external wrapper preserve a fresh request context by invoking servlet-per-request? The choice affects whether the same write operation is performed multiple times or whether the request is re‑executed in isolation.

Questions

• What guarantees does servlet-loop provide regarding the isolation of mutable request state across retries?
• How can an external retry wrapper reliably reconstruct the original request parameters without losing context?
• Is there a recommended pattern in the Racket documentation to combine retries with idempotent writes?