Home/ Questions/Q 897727
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T14:55:43+00:00

Background WCF Stack, Data Access Implemented in Entity Framework, Simple ASP.NET Front End This

  • 0

Background WCF Stack, Data Access Implemented in Entity Framework, Simple ASP.NET Front End

This is a two part question.

Recently we ran into an issue with periodic crashes with an exception that read:

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

We had been running our application without issues for over a week, and then all the sudden we were hit with this random crash/ If I had to guess I would say it was network related, but we were unable to determine the exact source. Has anyone periodically gotten this message? If so what was the root cause?

Second question is someone suggested to set “async=true” in our Entity Framework connection string. I was under the impression this just enables the async api. Does this do anything when you are using EF? Does switching this flag do anything with the queries that get generated by EF?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To be that guy I will answer this one on my own.

    First I posted the question about the “async=true”s effect on entity framrwork to MS and no one answered … as usual(if they answer i will update this post).

    Our issue:

    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

    Was environment related. Something was causing the DB to run a little bit slower, but it was hinting to a larger issue. Apparently EF has horrible issues when you share context between threads (not an easy problem to solve), so we were seeing a race condition with opening connections.

    We basically had a “read only context” that only did gets. Our issue was two threads attempt to open the connection at the same time, one wins, the other loses resulting in some variation of the exception below:

    The connection was not closed. The connection’s current state is connecting.

    Our solution was to convert our singleton to be thread specific. Not exactly what we wanted, but it worked, and when we pushed this fix our other issue magically went away.

    The second half to this question was what does async=true do. When it comes to EF, it made our system crash. We had a block of code that did a join, and if async=true and MARS=false we got a:

    There is already an open DataReader associated with this Command which must be closed first

    Once we cut back on MARS, and disabled async things were good again.

    • 0