ServiceManager Shared Instances vs Non-Shared Factories for State Isolation

Answering the Question

In a Laminas ServiceManager, the shared flag determines whether a service instance is cached for the lifetime of the container. The trade‑off is between the cost of constructing a fresh instance on every get() call (non‑shared) and the risk that a mutable instance may expose request‑specific data to unrelated components (shared).

When Overhead Wins

• Construction is expensive (e.g., heavy database connections, HTTP clients, or complex object graphs).
• Retrievals are infrequent within a single request, or the service is stateless and accepts all context as method arguments.
• The container is short‑lived per request (typical PHP‑FPM, FastCGI, or single‑threaded Swoole workers). In this scenario, shared instances cannot leak across requests, so the construction cost dominates.
• The service does not store mutable request data in instance properties.

When State Leakage Wins

• The container outlives a single request (long‑running Swoole, RoadRunner, or ReactPHP workers). Shared instances may persist across requests and propagate stale data.
• The service holds request‑specific state in instance properties (e.g., a form validator that caches the current request’s input).
• Multiple components within the same request must not see each other’s state—e.g., two independent handlers that both consume the same service but should operate on isolated data.
• The service’s constructor embeds request context (e.g., passing the current Request object to the constructor).

Dynamic Request‑Based Services

For services that must adapt to the current request (e.g., a translator that loads locale data or a logger that tags messages with a request ID), the recommended pattern is:

1. Register the service as shared (default).
2. Keep the service stateless; accept the request or context as a method argument.
3. If the service truly needs to embed context in its instance (e.g., a per‑request cache), register it as shared" => false and ensure the factory uses the current request to build the instance.
4. In long‑lived containers, add an explicit reset or factory that discards the old instance before re‑instantiation.

Practical Steps for Your Project

1. Inspect the container lifecycle. Confirm whether the ServiceManager is recreated per request or persists across requests.
2. Audit the service class. Look for mutable properties that are set from request data. If any exist, consider making the service non‑shared or refactoring to stateless design.
3. Measure construction cost. Add a simple log or counter in the factory and call get() multiple times in a test request. Compare the time taken for shared vs non‑shared.
4. Check request context usage. If the service receives the request in its constructor, it is a candidate for shared => false unless the container is per‑request.
5. Review concurrency model. In PHP‑FPM each worker is isolated, so shared instances do not cross requests. In Swoole or RoadRunner, shared instances can persist; adjust accordingly.

Missing Diagnostic Detail

To refine the recommendation, please confirm: Does your ServiceManager instance live only for the duration of a single HTTP request, or does it persist across multiple requests in a long‑running environment (e.g., Swoole, RoadRunner, or a single ReactPHP loop)?