nolock/TransactionScope vs snapshot-изоляция

Question

Следует использовать изоляцию снимка вместо nolock/TransactionScope? Снимок выглядит как параметр db, который применяется к базе данных в целом? Правильно ли это, и это означает, что мне не нужно специально кодировать его?

Если я обновляю связанные таблицы, а затем SubmitChanges(), будет ли linq всегда обновлять таблицы в том же порядке?

Благодаря

Answer 1

Во-первых, NOLOCK (и ReadUncommitted) чрезвычайно опасны. Подумайте, вы используете транзакции в основном потому, что хотите, чтобы ваши данные были согласованными. Используя NoLock, вы разрешаете грязные чтения ваших данных. Скажите, что в вашем приложении очень возможно, что вы читаете половину обновленных или частично вставленных данных. Ваше приложение (или пользователи) будет принимать решения на основе несогласованных данных.

Если вы перейдете к делу и просто спросите, могут ли данные, на которые работает ваше приложение, быть непоследовательными, я считаю, что ответ будет строго НЕТ. Так что просто не принимайте этот путь, мы были там, это ни к чему.

Теперь о заказе. Насколько я понимаю, теоретически не гарантируется, будет ли он всегда одного и того же порядка или нет, но практически он, вероятно, будет (поскольку ORM обычно имеют только один алгоритм для перечисления сущностей и обнаружения изменений). Но это не помогает, потому что даже он перечисляет сущности (чтобы найти то, что нужно сохранить) в том же порядке, количество типов объектов может быть различным. Скажем, это A и D в одном сценарии и A, B, D в другом и A, C, D в другом. Теперь это может зависеть от отношений между этими объектами. Скажем, C зависит от D, поэтому фактический порядок будет фактически A, D, C, а не A, C, D (и даже здесь не указано, что это не будет D, C, A). Таким образом, ретрансляция на этом заказе не является вариантом. Единственное, что вы можете сделать, чтобы обеспечить заказ - вызвать .SaveChanges() после каждого шага, который неприятен.

Да, вы можете использовать уровень изоляции моментальных снимков (есть два, в основном любой из них, попробуйте снятие моментальных снимков). Это значительно уменьшит количество тупиков в вашей системе, но этот метод имеет свои недостатки.

Чтобы решить проблему более или менее правильно, я бы рекомендовал вам четко определить границы транзакций в вашей системе. Какая часть системы «владеет» данными? Какие данные должны быть изменены в соответствии с другими данными? Тогда вы сможете сказать: «разрешены только эти транзакции» и «только этой конкретной части моей системы разрешено касаться этих конкретных данных».

Это тяжело, особенно в начале, когда у вас есть большая база данных, которая читается и записывается хаотично, все отовсюду. Но это приводит к более стабильной, управляемой и поддерживаемой системе.

BTW, Уди Даан имеет интересный пост в блоге об этом: Inconsistent data, poor performance, or SOA – pick one