Handling concurrency when adding rows to a table with key constraints - sql

Question

I am trying to handle concurrency in an "add-if-not-already-there" operation in .Net Core EF as follows:
internal static Folder GetOrCreateFolder(DbContext dbContext, User user, string folderNature, string folderName)
{
Folder folder = GetExistingFolder(dbContext, folderNature, folderName);
if (folder == null)
{
try
{
folder = new Folder()
{
CreatedBy = user,
CreatedDate = DateTime.UtcNow,
Nature = folderNature,
Name = folderName
};
dbContext.Folders.Add(folder);
dbContext.SaveChanges();
}
catch
{
// see if the record has already been created in another call
folder = GetExistingFolder(dbContext, folderNature, folderName);
if (folder == null) // something else is wrong
{
throw;
}
}
}
return folder;
}
The problem is that the second attempt to get the row when it has already been created also fails, throwing an exception: Cannot insert duplicate key row in object 'dbo.Folders' with unique index 'IX_Folders_Name_Nature'. The duplicate key value is...
UPDATE: Here is the GetExistingFolder method:
private static Folder GetExistingFolder(CMSDbContext dbContext, string folderNature, string folderName)
{
return dbContext.Folders.FirstOrDefault(f => f.Nature == folderNature && f.Name == folderName);
}
The code seems like it should be able to handle this situation, but why am I still getting that error? Thanks!

Answer 1

So here is the remedy:
First, here is the procedure using one transient dbcontext in each thread:
Get or create a row in parent table - commit if parent row is missing
Create a child row in child table and commit
Now, two concurrent requests needed to create the same parent row. At the beginning, the parent row is not there, so both attempt to create it. Needless to say, only one succeeds when committing due to constraints on the parent table. Knowing that the parent row may have been created in another thread, I accounted for that by re-examining the parent table when this happens to see if the required row is already there -- if yes, we are good, and we can proceed to step 2 without committing.
What I missed once I figured that the parent row has already been created in another thread, was that I should have also removed it from dbcontext change history using:
dbContext.ParentTable.Remove(parentRowThatHasAlreadyBeenCreated);
So its creation would not be attempted during the commit for the child row. So essentially there should be a step 2.5, where an unsuccessful commit to parent table is cleaned up.