3

У меня есть рабочая роль, разработанная с помощью ASP.NET MVC 4, которая реализует REST WS в Azure. Он использует Entity Framework v6 для подключения к Azure SQL DDBB. Обычно он работает нормально, но иногда я получаю исключение, когда пытается writte в DDBB с этим сообщением:Как обрабатывать ошибки соединения с SQL Azure DDBB с EF6

ошибка сообщается при совершении транзакции базы данных, но это не удалось определить, удалось ли сделка или не на сервер баз данных

Ошибка, связанная с проблемой соединения между Aplication Sever и DDBB. Я применил SQLAzureExcutionStrategy (пояснил here), чтобы получить отказоустойчивость соединения, но это не мешает ошибке, поскольку проблема соединения возникает во время фиксации, поэтому EF не знает, нужно ли повторять попытку или нет.

Существует пояснение here, в котором предлагается создать «контрольную таблицу дорожек», чтобы вставить «последовательность треков» в каждую транзакцию, и если произойдет переходное исключение (как мое), проверьте, существует ли строка или нет в таблице, чтобы решить retring или нет. Но я не уверен, что этот подход действителен при использовании ORM, например EF.

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

Заранее благодарим за любую помощь, которую вы можете предоставить.

С уважением, Ivan.

+0

я, наконец, получить ответ от Microsoft. Я еще не тестировал, но выглядит так: https://msdn.microsoft.com/en-us/data/dn630221 –

ответ

0

Если вы не начать начать транзакцию самостоятельно, SQLAzureExcutionStrategy поддерживает DbContext.SaveChanges() (это не имеет значения, сколько entites там). Проверьте here.

В противном случае, если вам действительно нужно использовать контрольная таблица трека. Что произойдет, если вы получите ошибку соединения во время проверки? Вам также нужно больше работать, чтобы справиться с этим. Вы должны сделать это для всех транзакций. Потому что вы не знаете, какая из них даст ошибку. Ошибки очень редки. Итак, это очень дорого.

Если вы можете последовать решение между не делать ничего и использовать базу данных для сброса состояния. Показать/вернуть значащее сообщение пользователю ничего не делать. Я следую этому решению, и этого достаточно для меня.

Мое предложение: Если вы не начать транзакцию самостоятельно продолжить SQLAzureExcutionStrategy. В противном случае попробуйте выбрать лучшее решение для вас, начиная проверять самый дешевый (Ничего не делать).

+0

Привет, Erkan, спасибо за ваш ответ и извините за мой поздний ответ. Я не использую транзакцию самостоятельно, но SQLAzureExcecutionStrategy не работает в этом сценарии. Ошибка соединения происходит во время транзакции, и EF не может знать, нужно ли повторять попытку или нет. Фактически в некоторых случаях исключение происходит, но фиксация выполнена. Я сделал обновление AzureDDBB от S0 до S20, и теперь эти ошибки подключения не hapenning. –

0

Наилучший подход - сделать вариант 3 в статье.Лучший способ сделать это является использование хранимых процедур для записи и считывания информации, следуя рецепту ниже:

Вариант 3 - вручную отслеживать транзакции

  1. Добавить не-гусеничный таблицы в базе данных, используемой для отслеживать состояние транзакций.
  2. Вставьте строку в таблицу в начале каждой транзакции.
  3. Если соединение не выполняется во время фиксации, проверьте наличие соответствующей строки в базе данных. Если строка присутствует, продолжайте нормально, по мере успешного совершения транзакции Если строка отсутствует, используйте стратегию выполнения, чтобы повторить текущую операцию.
  4. Если фиксация выполнена успешно, удалите соответствующую строку, чтобы избежать роста таблицы.

Таблицу дорожек не следует открывать. Вот почему мы должны инкапсулировать все в хранимых процедурах.

Спасибо, Михаэла

+0

Привет, Михаэла, спасибо за ваш ответ и извините за мой поздний ответ. Я думаю (я не уверен, что причина моего вопроса), что этот параметр не является надежным с использованием EF в качестве DBContext.SaveChanges() может обрабатывать разные коммиты. Я сделал обновление AzureDDBB от S0 до S20, и теперь эти ошибки подключения не hapenning. –