To handle background and recurring tasks on our app we're using Quartz.net running in the background.
We have a quartz IJobListener that starts a child container and autowires the job instance dependencies, in a similar fashion to service instances.
We want to have the same IoC registrations for code running on the quartz threads that we have for our services.
When using a ReuseScope of Request, we want a new dependency instance per job instance, the same way an http request has new instances. For request scope the instances are stored on
RequestContext.Instance.Items, which are cleared on
Would it be correct to just call EndRequest when the job is finished to clear that scope? That wouldn't call
.Dispose() on IDisposables, or would it?
Personally I'd avoid using RequestScope in a background workers. But you'd want to call:
Which would call Dispose on IDisposables.
But container scope wouldn't get disposed at the end of a request, or would it? If we want to share registrations between background and services, can we really avoid RequestScope?
It only disposes RequestScope and transient IDisposable instances resolved during the request.
You wont be able to share RequestScope instances between background workers and HTTP Services which are tied to the HTTP Worker Thread's Request Context.
I'd always avoid RequestScope dependencies in MQ or bg threads. Resolving singleton or new transient instances are much easier to reason about.
Sorry, I might have mispoken. I don't want to share RequestScope instances, just their wiring on funq.
I think of RequestScope as a unit of work, and I want to consider a quartz job to be like a request in that way. All our background work runs in a job, so that makes it easier to reason about (job == request). Thanks