Async = true и Entity Framework - PullRequest
       14

Async = true и Entity Framework

4 голосов
/ 30 июня 2010

Фоновый стек WCF, доступ к данным, реализованный в Entity Framework, простой интерфейс ASP.NET

Это вопрос из двух частей.

Недавно мы столкнулись с проблемой периодических сбоев, за исключением следующего:

Произошла ошибка транспортного уровня при получении результатов с сервера.(провайдер: провайдер TCP, ошибка: 0 - указанное сетевое имя больше не доступно

Мы запускали наше приложение без проблем более недели, а затем внезапно нас поразило этослучайный сбой / Если бы мне пришлось угадывать, я бы сказал, что это связано с сетью, но мы не смогли определить точный источник. Кто-нибудь периодически получал это сообщение? Если да, то какова была основная причина?

Второй вопроскто-то предложил установить «async = true» в нашей строке подключения Entity Framework. У меня сложилось впечатление, что это просто включает async api. Делает ли это что-нибудь, когда вы используете EF?по EF?

1 Ответ

6 голосов
/ 01 июля 2010

Чтобы быть тем парнем, я сам отвечу на него.

Сначала я опубликовал вопрос о влиянии "async = true" на фреймворк объекта на MS , и никто не ответил ... как обычно (если они ответят, я обновлю этот пост).

Наш выпуск:

Произошла ошибка транспортного уровня при получении результатов с сервера. (провайдер: провайдер TCP, ошибка: 0 - указанное сетевое имя больше не доступно

Был связан с окружающей средой. Что-то заставляло БД работать немного медленнее, но намекало на большую проблему. По-видимому, у EF возникают ужасные проблемы, когда вы делитесь контекстом между потоками (решить эту проблему непросто), поэтому мы наблюдали состояние гонки с открытием соединений.

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

Соединение не было закрыто. Текущее состояние соединения - это соединение.

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

Вторая половина этого вопроса была о том, что делает async = true. Когда дело доходит до EF, это приводило к краху нашей системы. У нас был блок кода, который сделал соединение, и если async = true и MARS = false, мы получили:

Уже есть открытый DataReader, связанный с этой Командой, который должен быть закрыт первым

Как только мы сократили MARS , и отключенные асинхронные операции снова стали хорошими.

...