后台WCF堆栈，在实体框架中实现了数据访问，简单ASP.NET前端Async = true和实体框架
这是一个两部分问题。
最近，我们遇到了一个问题，与一个例外，上面写着周期性崩溃：
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available
我们已经运行我们没有问题申请了一个多星期，然后所有的突然，我们击中了与该随机崩溃/如果我不得不猜测，我会说这是网络相关的，但我们无法确定确切的来源。是否有人定期收到此消息？如果是的话，根源是什么？
第二个问题是有人建议在我们的实体框架连接字符串中设置“async = true”。我之前的印象只是启用了异步API。当您使用EF时，这会做什么吗？切换此标志是否对EF生成的查询执行任何操作？
为了成为那个人，我会自己回答这个问题。
首先，我发布了关于“async = true”对实体框架的影响的问题至MS，并且没有人像往常一样回答...（如果他们回答我将更新此帖子）。
我们的问题：
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available
当时的环境有关。有些事情导致数据库运行速度稍慢，但这暗示了一个更大的问题。显然，当你在线程之间共享上下文时（不是一个容易解决的问题），EF有着可怕的问题，所以我们看到了开放连接的竞争状态。
我们基本上只有一个“只读上下文”，只有得到。我们的问题是两个线程试图打开在同一时间，1个胜场的连接，其他输了球导致下面的异常的一些变化：
The connection was not closed. The connection's current state is connecting.
我们的解决方案是我们的单转换为是线程特定的。不完全是我们想要的，但它的工作，当我们推动这个修复时，我们的另一个问题神奇地消失了。
这个问题的后半部分是async = true做的。说到EF，它让我们的系统崩溃了。我们有代码，没有一个加入一个块，如果异步=真，MARS =假，我们得到了：
There is already an open DataReader associated with this Command which must be closed first
一旦我们削减MARS，并禁用异步事情好了起来。