DbContext for background tasks via Dependency Inje

问题:

I am probably not thinking in the right direction. I am fairly new to Dependency Injection and ASP.Net Core.

I have a ASP.Net core website, and one of the tasks is to import data from an excel sheet to a database that a user will upload. The excel sheets can be huge and the data transformation tasks are time taking, hence I wish to perform them in the background. i.e. The user will upload the sheet, the response will be sent immediately and the background job/thread will import the data.

I am trying to run the background job by:

Task.Run(() => ProcessImport(model));

The problem I run into is that the Process import method calls Services that have repository classes accessing the AppDbContext via ASP.Net Dependency Injection Container that is added as Scoped and once the response is sent back, the context is disposed. I am getting a runtime exception that you cannot use a context after its disposed.

My Question is, what is the best way to handle this situation? Should I make the AppDbContext singleton? Should I create a new instance of AppDbContext in the ProcessImport method, and pass it along? I have read DbContext is not thread safe, so is that a good approach?

回答1:

You should pass IServiceScopeFactory instance (it's singleton) into your task.

Inside task, when data arrives, you should create new CreateScope() and request services from that scope. When data process finishes - dispose this scope (but hold reference to IServiceScopeFactory for next run).

See this for example. I run small and fast tasks with this library.

For heavy / long running tasks, as Gert wrote, don't rely that your task will always run to completion. Be ready for restart, be ready for re-processing of the same data.

回答2:

To breakdown your questions:

1. what is the best way to handle this situation?

   It's not ideal for the API to handle the long-running tasks. You can delegate the process to a background application

2. Should I make the AppDbContext singleton?

   The dbContext should not be singleton in a web application scenario as it can pose problems like managing transactions.

3. what is the best way to handle this situation?

   breakdown the various services/process:

   • The API that will take a file. Ideally the API should just take the file as input and persist it to disk or to database.
   • A service that will process the file. Create this component/service as a separate library. Then consume this library from a console app. This way you can profile the performance. Make it fire and forget method by making it async method. This way you have flexibility of reusing your code.
   • If you don't expect a lot of file uploads, you can reuse the library at your API controller and execute the method using QueueBackgroundWorkItem. See here for reference: http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx

4. Should I create a new instance of AppDbContext in the ProcessImport method, and pass it along?

   Since it is not thread-safe, create and use a separate instance of your dbContext class in each thread.

5. I have read DbContext is not thread safe, so is that a good approach?

   For an in-depth guide of using EF dbContext, checkout this blog: http://mehdi.me/ambient-dbcontext-in-ef6/