Чтобы быть тем парнем, я сам отвечу на него.
Сначала я опубликовал вопрос о влиянии "async = true" на фреймворк объекта на MS , и никто не ответил ... как обычно (если они ответят, я обновлю этот пост).
Наш выпуск:
Произошла ошибка транспортного уровня при получении результатов с сервера. (провайдер: провайдер TCP, ошибка: 0 - указанное сетевое имя больше не доступно
Был связан с окружающей средой. Что-то заставляло БД работать немного медленнее, но намекало на большую проблему. По-видимому, у EF возникают ужасные проблемы, когда вы делитесь контекстом между потоками (решить эту проблему непросто), поэтому мы наблюдали состояние гонки с открытием соединений.
У нас в основном был «контекст только для чтения», который только получал. Наша проблема заключалась в том, что два потока пытались открыть соединение одновременно, один выигрывал, другой проигрывал, что приводило к некоторому варианту исключения ниже:
Соединение не было закрыто. Текущее состояние соединения - это соединение.
Наше решение состояло в том, чтобы преобразовать наш синглтон в конкретный поток. Не совсем то, что мы хотели, но это сработало, и когда мы исправили это, наша другая проблема волшебным образом исчезла.
Вторая половина этого вопроса была о том, что делает async = true. Когда дело доходит до EF, это приводило к краху нашей системы. У нас был блок кода, который сделал соединение, и если async = true и MARS = false, мы получили:
Уже есть открытый DataReader, связанный с этой Командой, который должен быть закрыт первым
Как только мы сократили MARS , и отключенные асинхронные операции снова стали хорошими.