Я нашел причину проблемы. Причина, по которой я не получил конфликт для свойства "my_int", заключается в том, что он не конфликтует со значением базы данных, которое context2 "знает". Я объясню это:
Я думал, что конфликт определяется как , когда значения сохраняемого объекта не равны значениям в базе данных . ЭТО НЕ !!!!
Конфликт определяется как , когда текущее значение в базе данных не равно исходному значению, знакомому контексту . Исходное значение - это значение, которое было в базе данных при выполнении запроса выбора.
Изучив пример в моем вопросе, когда context2 выбрал данные из базы данных для создания obj2, значениями свойств были: my_string: "value", my_int: 0. Это исходные значения.
Когда я пытался сохранить данные, LINQ-TO-SQL сравнивал исходные значения со значениями базы данных. Значения базы данных в это время (после сохранения obj1): my_string: "value1", my_int: 0
В результате я получил конфликт в my_string (оригинал: «значение», база данных: «значение1»), но не в my_int (оригинал: 0, база данных: 0).
Обнаружение этого помогло мне понять, почему нет конфликта, но все же это не помогло мне решить проблему, потому что неправильное значение не было сохранено в базе данных, потому что я проанализировал только MemberChangeConflicts, который существует в ObjectChangeConflict, и если свойство, которое я проверяю, там не существует, логика проверки пропускается.
Решением было проанализировать также перечислимые измененные члены, которые предоставляют доступ ко всем измененным свойствам, и для каждого я могу получить исходное значение и новое значение.
Чтобы получить измененные члены, необходимо выполнить метод GetModifiedMembers. Этот метод находится в таблице типа данных объекта и может быть выполнен следующим образом:
var mmc = context.MyTable.GetModifiedMembers(myobject);
Объединение конфликтов и модифицированных участников дало мне полное представление о том, что случилось с объектом, вызвавшим конфликт, и правильно его обработало.
Спасибо за Damien_The_Unbeliever за подсказку в своем комментарии.