One thing to bear in mind about using entity framework is that the DbContext object is not thread safe. This threw me when I first discovered it; it also confused why I was getting this error, as I was running in an environment that I thought was pretty much single threaded (in fact, it was an Azure function). I was using IoC and so the DbContext is shared across instances.
Because the error is based on, effectively, a race condition, your mileage may vary, but you’ll typically get one of the following errors:
System.InvalidOperationException: ‘The context cannot be used while the model is being created. This exception may be thrown if the context is used inside the OnModelCreating method or if the same context instance is accessed by multiple threads concurrently. Note that instance members of DbContext and related classes are not guaranteed to be thread safe.’
System.InvalidOperationException: ‘A second operation started on this context before a previous operation completed. Any instance members are not guaranteed to be thread safe.’
I had a good idea what the cause of this might be, but in order to investigate, I set-up a console app accessing Entity Framework; in this case, EF Core.
If you’re here to find a solution, then you can probably scroll down to the section labelled To Fix.
Reproducing the error
To reproduce the error, we need to introduce Unity (I imagine the same would be true of any IoC provider, as the problem is more with the concept than the implementation):
Install-Package Unity
The next step is to abstract away the data access layer, in order to provide a base for our dependency injection:
As you can see, we’re introducing a data access layer - and we’re creating an interface for our DbContext. The idea being that this can subsequently be resolved by Unity. Here are our interfaces:
public interface IDataAccess
{
List<string> GetData();
void AddData(List<string> newData);
}
public interface IMyDbContext
{
DbSet<MyData> MyData { get; set; }
void SaveChanges();
}
public interface IDoStuff
{
void DoStuffQuickly();
}
Finally, we can implement the interfaces:
public class DataAccess : IDataAccess
{
private readonly IMyDbContext \_myDbContext;
public DataAccess(IMyDbContext myDbContext)
{
\_myDbContext = myDbContext;
}
public void AddData(List<string> newData)
{
foreach (var data in newData)
{
MyData myData = new MyData()
{
FieldOne = data
};
\_myDbContext.MyData.Add(myData);
}
\_myDbContext.SaveChanges();
}
public List<string> GetData()
{
List<string> data =
\_myDbContext.MyData.Select(a => a.FieldOne).ToList();
return data;
}
}
The DbContext:
public class MyDbContext : DbContext, IMyDbContext
{
public DbSet<MyData> MyData { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
string cn = @"Server=.\\SQLEXPRESS;Database=test-db . . .";
optionsBuilder.UseSqlServer(cn);
base.OnConfiguring(optionsBuilder);
}
void IMyDbContext.SaveChanges()
{
base.SaveChanges();
}
}
Let’s register a class to actually start the process:
public class DoStuff : IDoStuff
{
private readonly IDataAccess \_dataAccess;
private readonly ILogger \_logger;
public DoStuff(IDataAccess dataAccess, ILogger logger)
{
\_dataAccess = dataAccess;
\_logger = logger;
}
public void DoStuffQuickly()
{
\_dataAccess.AddData(new List<string>()
{
"testing new data",
"second test",
"last test"
});
Parallel.For(1, 100, (a) =>
{
List<string> data = \_dataAccess.GetData();
foreach(string text in data)
{
\_logger.Log(text);
}
});
}
}
Now let’s register the types in out IoC container:
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
UnityContainer container = new UnityContainer();
container.RegisterType<IDataAccess, DataAccess.DataAccess>();
container.RegisterType<IMyDbContext, MyDbContext>();
container.RegisterType<IDoStuff, DoStuff>();
container.RegisterType<ILogger, ConsoleLogger>();
container.Resolve<IDoStuff>().DoStuffQuickly();
}
(Console logger is just a class that calls Console.WriteLine()).
Now, when you run it, you’ll get the same error as above (or something to the same effect).
To fix
One possible fix is to simply instantiate a DbContext as you need it; for example:
public List<string> GetData()
{
using (var myDbContext = new MyDbContext())
{
List<string> data =
myDbContext.MyData.Select(a => a.FieldOne).ToList();
return data;
}
}
However, the glaring problem that this creates is unit testing. The solution is a simple factory class:
public interface IGenerateDbContext
{
IMyDbContext GenerateNewContext();
}
public class GenerateDbContext : IGenerateDbContext
{
public IMyDbContext GenerateNewContext()
{
IMyDbContext myDbContext = new MyDbContext();
return myDbContext;
}
}
We’ll need to make the DbContext implementation disposable:
public interface IMyDbContext : IDisposable
{
DbSet<MyData> MyData { get; set; }
void SaveChanges();
}
And, finally, we can change the data access code:
public void AddData(List<string> newData)
{
using (IMyDbContext myDbContext = \_generateDbContext.GenerateNewContext())
{
foreach (string data in newData)
{
MyData myData = new MyData()
{
FieldOne = data
};
myDbContext.MyData.Add(myData);
}
myDbContext.SaveChanges();
}
}
public List<string> GetData()
{
using (IMyDbContext myDbContext = \_generateDbContext.GenerateNewContext())
{
List<string> data =
myDbContext.MyData.Select(a => a.FieldOne).ToList();
return data;
}
}
Now we can use IoC to generate the DBContext, and therefore it is testable, but we don’t pass the DbContext itself around, and therefore there are no threading issues.