CODEWITHSUNDEEP
servicestack
boyan
boyan

Reputation: 1125

ServiceStack service being singleton by default may cause its request context to be corrupted?

My ServiceStack implementation has service implementations that rely on the HTTP cookies / request. Let's assume the following scenario.

On the very first authenticated user request, the ServiceStack AppHost is able to resolve a service, injects it with the user's RequestContext (request, response, cookies etc) and off we go. Let's assume that this request actually takes a while to process.

Note that by default (from the ServiceStack documentation) the service instance actually comes from a singleton.

By default all dependencies registered in Funq have singleton scope, where the same instance is injected into all dependencies.

Consider now a separate request by a second, different user, when the first user request has yet to finish executing. AppHost resolves the service instance again, and injects the second user's RequestContext. Let's also assume that this request takes a while to process.

If by now the first user thread regains control and has to read its RequestContext from the service instance - wouldn't it now be corrupted from the second request?

Understandably I can configure the service instances to be of request-lifetime, but is it correct to assume that by going over the scenario above I may easily run into request context corruption?

Upvotes: 2

Views: 718

Answers (1)

SteveChapman
SteveChapman

Reputation: 3081

The quote in your question relates to manually registered dependencies, which by default are singleton unless you specify otherwise. Auto-wired services are registered in the container as ReuseScope.None.

If you're registering services manually, you should probably use IAppHost.RegisterService(Type serviceType, params string[] atRestPaths) which also registers services as ReuseScope.None.

Upvotes: 1

Related Questions