Question

OK, so you think you’re a real debugger? Try this one:

I’ve got a Linq2Sql project where suddenly we’ve discovered that occasionally, seemingly randomly, we get double-inserts of the same row.

I have subclassed DataContext and overridden SubmitChanges. Inside there I have made a call to GetChangeSet(), both before and after the call to base.SubmitChanges(), and used a text file logger to record the objects in the Inserts collection. Plus I hang on to a reference to the inserted objects long enough to record their autonumbered ID.

When the double-insert happens, I see in the DB that instead of one row each being inserted into MyTableA and MyTableB, there are two each. SQL Profiler shows four insert statements, one after the other in rapid succession:

insert into MyTableA(...
insert into MyTableB(...
insert into MyTableA(...
insert into MyTableB(...

I check in the debug log, and there are only two objects in the Inserts collection: one of MyClassA and one of MyClassB. After the call to base.SubmitChanges(), the changeset is empty (as it should be). And the autonumber IDs show the larger value of the newly inserted rows.

Another piece of useful information: the bug never happens when stepping through in debug mode; only when you run without breakpoints. This makes me suspect it’s something to do with the speed of execution.

We have been using the same DataContext subclass for over a year now, and we’ve never seen this kind of behavior before in our product. It only happens with MyClassA and MyClassB.

To summarize:

1. From the debug log, everything looks like it’s working correctly.
2. On SQL Profiler, you can see that a double-insert is happening.
3. This behavior happens frequently but unpredictably, only to the two classes mentioned, excepting that it never happens when stepping through code in debug mode.

EDIT – New information:
Inside my DataContext subclass, I have the following code:

try {
  base.SubmitChanges(ConflictMode.ContinueOnConflict);
} catch (ChangeConflictException) {
  // Automerge database values for members that client has not modified.
  foreach (ObjectChangeConflict occ in ChangeConflicts) {
    occ.Resolve(RefreshMode.KeepChanges);
  }
}
// Submit succeeds on second try.
base.SubmitChanges(ConflictMode.FailOnFirstConflict);

MyTableA and MyTableB both have a mandatory foreign key OtherTableID referencing OtherTable. The double insert happens when a ChangeConflictException happens during an update of the common parent table OtherTable.

We’re on the scent, now…

Answer 1

looks like it’s a BUG in Linq2Sql! Here’s a repeatable experiment for you:

using (var db1 = new MyDataContext()) {
  var obj1 = db1.MyObjects.Single(x => x.ID == 1);
  obj1.Field1 = 123;
  obj1.RelatedThingies.Add(new RelatedThingy {
                           Field1 = 456,
                           Field2 = "def",
                           });
  using (var db2 = new MyDataContext()) {
    var obj2 = db2.MyObjects.Single(x => x.ID == 1);
    obj2.Field2 = "abc";
    db2.SubmitChanges();
  }
  try {
    db1.SubmitChanges(ConflictMode.ContinueOnConflict);
  } catch (ChangeConflictException) {
    foreach (ObjectChangeConflict occ in ChangeConflicts) {
      occ.Resolve(RefreshMode.KeepChanges);
    }
  }
  base.SubmitChanges(ConflictMode.FailOnFirstConflict);
}

Result: MyObject record with ID = 1 gets updated, Field1 value is 123 and Field2 value is “abc”. And there are two new, identical records inserted to RelatedThingy, with MyObjectID = 1, Field1 = 456 and Field2 = “def”.

Explain THAT!

UPDATE: After logging this on Microsoft Connect, the nice folks at MS asked me to put together a little demo project highlighting the bug. And wouldn’t you know it – I couldn’t reproduce it. It seems to be connected to some weird idiosyncrasy of my project. Don’t have time to investigate further, and I found a workaround, anyway…