-1

I get into a problem when I tried to perform asynchronous operations on a database that was registered as a singleton. I was getting the error which is solved in this question One of the most popular options is to register the service as transient bsc Entity Framework Core does not support multiple parallel operations being run on the same DbContext instance.

But then I'll get a new database instance every time, which won't allow me to implement a save function with bool commit = false

Example:

TransportService.SaveTransport(transportSaveDto, commit:false); DriverService.SaveDriver(driverSaveDto, commit:false); 
LotService.SaveLot(lotSaveDto, commit:true);

SaveChanges() will be invoke only in SaveLot and must save all dtos, but if I will have new db instance every time - driver and transport will not be saved

First of all, how bad is it to create a new database instance every time? Does constant creation justify itself when the opportunity to perform asynchronous operations appears?

Is there no adequate way to still leave the db in singleton and get the ability to perform asynchronous operations on one database context?

  • 1
    You are not creating a new database with every new DbContext instance, this only creates a DbContext instance that points to an existing database. This is a common practice but you can use the same dbcontext across layers in your application which could be common in an asp.net application where a dbcontext instance is tied to a request. I would not recommend you use a singleton though, that is setting your code up for race condition problems and other problems that might be a bear to debug later to figure out what happened. – Igor Aug 30 '23 at 13:38
  • 2
    Also async operations can be misleading. An async action method is not the same thing as a parallel operation (things you want to happen simultaneously). If you just mean something like SaveAsync these methods exist to offload I/O from the thread so the thread is not tied up and can be reused to serve other requests. This is useful in asp.net applications or in gui applications where the operation should not tie up the main window thread which would cause the ui to hang. – Igor Aug 30 '23 at 13:43
  • 1
    If you want to execute processes on the same dbcontext instance simultaneously you are likely out of luck as that is not supported. For this you should use multiple dbcontext instances or wait until an operation completes before starting the next if you are writing related data. – Igor Aug 30 '23 at 13:44
  • Related: https://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why – Steven Aug 30 '23 at 14:05
  • 1
    *So I have a few questions* -- That in itself makes a question off-topic on Stack overflow. But your question is far too sketchy anyway. Try to focus on one case. Show code (i.e. a [mre]). Show what it means to "implement a save function with bool commit = false" (or true). – Gert Arnold Aug 30 '23 at 14:45
  • 1
    A DbContext is a unit of work, not a database, connection or database model. It doesn't *have* to allow concurrent operations because it doesn't even connect to the database until it has to either load data, or persist *all* changes made to the objects it tracks in a single database transaction, when you call `SaveChanges`. As it's a UoW, its scope is the *business operation*, not the service or anything else. In a web application, the scope is the HTTP request which gives `transaction-per-request` behavior out of the box – Panagiotis Kanavos Aug 30 '23 at 16:07
  • If you worry about connections, that's not the job of DbContext at all. The unredlying data access library, ADO.NET, and the specific database drivers like NpgSql or Microsoft.Data.SqlClient take care of pooling and reusing connections as needed. Connections are meant to be short-lived which is why you always see them created in `using` blocks. The connection pool takes care of reseting any disposed connections and putting them back in the pool. – Panagiotis Kanavos Aug 30 '23 at 16:10

0 Answers0