Как откат транзакции связан с LINQ to SQL?

Question

Вопрос только в том, чтобы откатить изменения, а не фиксировать.

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

Но я обнаружил, что это наполовину правда - LINQ DataContext сохранит измененные данные! Я проверил это, используя TransactionScope и DataContext.Transaction. В обоих случаях у меня одинаковое поведение.

Обходным путем будет воссоздание DataContext после отката (однако это приводит к другим проблемам, таким как кеширование данных и обработка вложенных транзакций) или ручное отклонение изменений в DataContext. Тем не менее, это всего лишь обходные пути.

Вопросы

Так чего мне не хватает? LINQ to SQL не подходит для транзакций? Как использовать транзакции, чтобы они ДЕЙСТВИТЕЛЬНО откатывали изменения?

Пример

                MyTable record = null;

                db.Connection.Open();
                using (db.Transaction = db.Connection.BeginTransaction())
                {
                        record = db.MyTable.First();
                        record.BoolField = !record.BoolField; // changed
                        db.SubmitChanges();
                        db.Transaction.Rollback();
                }

Answer 1

Контекст данных следует рассматривать как единицу работы. То, как гранулированный вы делаете, зависит от вас - это может быть запрос страницы или одна операция; но - если вы получаете исключение (или почти что-нибудь неожиданное) - stop ; отказаться от контекста данных и отката. После отката ваш контекст данных будет сбит с толку, поэтому просто не сохраняйте его .

Дополнительно; не храните контекст данных дольше, чем необходимо. Он не предназначен для кэша данных в течение всего приложения.

Answer 2

То, что вы, похоже, запрашиваете, - это кэш базы данных в памяти (или некоторая его часть), а не облегченный ORM. Я бы сказал, что LINQ to SQL прекрасно подходит для транзакций и является легковесным ORM, но не настолько хорош для использования в качестве кеша базы данных. На мой взгляд, контекст данных лучше всего работает с использованием шаблона «Единица работы». Создайте контекст для конкретной задачи, выполните задачу, затем избавьтесь от контекста. Если в задачу входит неудачная транзакция, вам необходимо выяснить, как реагировать на ошибку. Это может быть либо исправлением ошибок и повторением попыток с существующим контекстом, либо, как в веб-контексте, передачей попыток изменения пользователю, а затем повторной попыткой с новым контекстом при повторной отправке данных.

Answer 3

Две вещи:

1) устаревший текстовый текст

То, что вы наблюдаете, обычно называют «устаревшим» текстовым контентом. Сущности в текстовом тексте не замечают ваш роллбак. Вы получите симулированное поведение, если будете выполнять хранимую процедуру после ваших изменений. Это также не будет замечено текстом данных. Однако ваши транзакции будут откатываться в БД! (а также будет выполнена хранимая процедура)

2) о транзакциях

Нет необходимости управлять транзакцией. Linq2Sql уже создает транзакцию для вас в Submitchanges. Если вы действительно хотите управлять транзакциями (например, по нескольким текстовым текстам или хранимой процедуре в сочетании с некоторым linq2sql, оберните все это в TransactionScope. Вызовите транзакцию.Complete () в той точке, где вы хотите зафиксировать.