Комментарии 14
Спасибо, очень полезный материал.
Есть пара проблем в своем проекте, которые можно и нужно решить на уровне описанных выше конфликтов.
Есть пара проблем в своем проекте, которые можно и нужно решить на уровне описанных выше конфликтов.
+1
LINQ To SQL? Дайте ему спокойно умереть
-14
Было бы интересно узнать, как реализуется в Linq to SQL optimistic locking через version поля.
+2
Спасибо за Ваш интерес! Сегодня вечером (после работы) добавлю к статье способ работы с version полем
0
Добавил в статью пример с использованием поля версии
+1
вопрос: в последнем примере tranaction и db никак между собой не связаны — это так и задумано?
-1
// офф
что-то напомнило. «2 слесаря автоваза подрались из-за ведра с гайками.»
что-то напомнило. «2 слесаря автоваза подрались из-за ведра с гайками.»
-1
Очень хорошо написано, действительно для многих полезная статья получилась.
Одно только замечание — править значения в атрибутах все-таки лучше внутри .dbml или в дизайнере, поскольку при редактировании непосредственно файла .designer.cs ваши изменения могут затереться при изменении схемы DBML.
Одно только замечание — править значения в атрибутах все-таки лучше внутри .dbml или в дизайнере, поскольку при редактировании непосредственно файла .designer.cs ваши изменения могут затереться при изменении схемы DBML.
+1
Спасибо автору :)
Мучался из-за появляющегося конфликта при обновлении данных в двух таблицах одновременно (в БД еще триггер есть, который пока нельзя выпилить). как оказалось, конфликт был из-за атрибута IsVersion=true на поле одного из объектов.
При этом, что, цуко, странно, в объекте ObjectChangeConflict коллекция MemberConflicts была пустая, и непонятно было на каком именно поле конфликт произошел.
Если это ожидаемое поведение (пустая коллекция MemberConflicts при конфликте по версии) при возникновении исключения ChangeConflictException, то можно было бы добавить в статью в раздел про isVersion фразу про это :)
Мучался из-за появляющегося конфликта при обновлении данных в двух таблицах одновременно (в БД еще триггер есть, который пока нельзя выпилить). как оказалось, конфликт был из-за атрибута IsVersion=true на поле одного из объектов.
При этом, что, цуко, странно, в объекте ObjectChangeConflict коллекция MemberConflicts была пустая, и непонятно было на каком именно поле конфликт произошел.
Если это ожидаемое поведение (пустая коллекция MemberConflicts при конфликте по версии) при возникновении исключения ChangeConflictException, то можно было бы добавить в статью в раздел про isVersion фразу про это :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LINQ to SQL и конфликты параллельного доступа