Entity Framework: Z tym poleceniem jest już otwarty DataReader

Korzystam z Entity Framework i od czasu do czasu dostaję ten błąd.

EntityCommandExecutionException
{"There is already an open DataReader associated with this Command which must be closed first."}
   at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands...

Mimo że nie wykonuję żadnego ręcznego zarządzania połączeniami.

ten błąd zdarza się sporadycznie.

kod wywołujący błąd (skrócony dla ułatwienia odczytu):

        if (critera.FromDate > x) {
            t= _tEntitites.T.Where(predicate).ToList();
        }
        else {
            t= new List<T>(_tEntitites.TA.Where(historicPredicate).ToList());
        }

za pomocą opcji Usuń wzór, aby za każdym razem otwierać nowe połączenie.

using (_tEntitites = new TEntities(GetEntityConnection())) {

    if (critera.FromDate > x) {
        t= _tEntitites.T.Where(predicate).ToList();
    }
    else {
        t= new List<T>(_tEntitites.TA.Where(historicPredicate).ToList());
    }

}

wciąż problematyczne

dlaczego EF nie używałby połączenia, jeśli jest już otwarte.

Nie chodzi o zamykanie połączenia. EF poprawnie zarządza połączeniem. Rozumiem ten problem, ponieważ istnieje wiele poleceń pobierania danych wykonanych przy jednym połączeniu (lub pojedynczym poleceniu z wieloma zaznaczeniami), podczas gdy następny czytnik danych jest wykonywany przed zakończeniem odczytu. Jedynym sposobem uniknięcia tego wyjątku jest umożliwienie wielu zagnieżdżonych DataReaders = włączenie MultipleActiveResultSets. Innym scenariuszem, w którym zawsze tak się dzieje, jest iteracja przez wynik zapytania (IQueryable) i wyzwalanie leniwego ładowania dla załadowanej jednostki wewnątrz iteracji.

Alternatywnie do korzystania z MARS (MultipleActiveResultSets) możesz napisać kod, aby nie otwierać wielu zestawów wyników.

Możesz odzyskać dane do pamięci, w ten sposób nie będziesz mieć otwartego czytnika. Często jest to spowodowane iteracją zestawu wyników podczas próby otwarcia innego zestawu wyników.

Przykładowy kod:

public class MyContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }
}

public class Blog
{
    public int BlogID { get; set; }
    public virtual ICollection<Post> Posts { get; set; }
}

public class Post
{
    public int PostID { get; set; }
    public virtual Blog Blog { get; set; }
    public string Text { get; set; }
}

Powiedzmy, że przeprowadzasz wyszukiwanie w bazie danych zawierającej:

var context = new MyContext();

//here we have one resultset
var largeBlogs = context.Blogs.Where(b => b.Posts.Count > 5); 

foreach (var blog in largeBlogs) //we use the result set here
{
     //here we try to get another result set while we are still reading the above set.
    var postsWithImportantText = blog.Posts.Where(p=>p.Text.Contains("Important Text"));
}

Możemy to zrobić w prosty sposób, dodając .ToList () w następujący sposób:

var largeBlogs = context.Blogs.Where(b => b.Posts.Count > 5).ToList();

To zmusza encjifrfrowej do załadowania listy do pamięci, dlatego gdy iterujemy ją w pętli foreach, nie korzysta już z czytnika danych do otwierania listy, zamiast tego jest w pamięci.

Zdaję sobie sprawę, że może to nie być pożądane, jeśli chcesz na przykład załadować niektóre właściwości. Jest to głównie przykład, który, mam nadzieję, wyjaśnia, w jaki sposób / dlaczego możesz dostać ten problem, abyś mógł odpowiednio podejmować decyzje

Jest inny sposób na rozwiązanie tego problemu. To, czy jest to lepszy sposób, zależy od twojej sytuacji.

Problem wynika z leniwego ładowania, więc jednym ze sposobów uniknięcia tego jest brak leniwego ładowania, poprzez użycie opcji Dołącz:

var results = myContext.Customers
    .Include(x => x.Orders)
    .Include(x => x.Addresses)
    .Include(x => x.PaymentMethods);

Jeśli użyjesz odpowiednich Includeliter, możesz uniknąć włączenia MARS. Ale jeśli go przegapisz, pojawi się błąd, więc włączenie MARS jest prawdopodobnie najłatwiejszym sposobem na jego naprawienie.

Ten błąd pojawia się, gdy kolekcja, którą próbujesz iterować, jest swego rodzaju leniwym ładowaniem (IQueriable).

foreach (var user in _dbContext.Users)
{    
}

Przekształcenie kolekcji IQueriable w inną kolekcję wymienną rozwiąże ten problem. przykład

_dbContext.Users.ToList()

Uwaga: .ToList () tworzy nowy zestaw za każdym razem i może powodować problemy z wydajnością w przypadku dużych danych.

Rozwiązałem problem łatwo (pragmatycznie), dodając opcję do konstruktora. Dlatego używam tego tylko w razie potrzeby.

public class Something : DbContext
{
    public Something(bool MultipleActiveResultSets = false)
    {
        this.Database
            .Connection
            .ConnectionString = Shared.ConnectionString /* your connection string */
                              + (MultipleActiveResultSets ? ";MultipleActiveResultSets=true;" : "");
    }
...

Spróbuj ustawić parametry połączenia MultipleActiveResultSets=true. Umożliwia to wielozadaniowość w bazie danych.

Server=yourserver ;AttachDbFilename=database;User Id=sa;Password=blah ;MultipleActiveResultSets=true;App=EntityFramework

To działa dla mnie ... niezależnie od tego, czy połączenie w app.config, czy też ustawiasz je programowo ... mam nadzieję, że będzie to pomocne

Pierwotnie zdecydowałem się użyć pola statycznego w mojej klasie API, aby odwołać się do instancji obiektu MyDataContext (gdzie MyDataContext jest obiektem kontekstu EF5), ale to właśnie wydawało się stwarzać problem. Dodałem kod podobny do następującego do każdej z moich metod API i to rozwiązało problem.

using(MyDBContext db = new MyDBContext())
{
    //Do some linq queries
}

Jak zauważyli inni, obiekty kontekstu danych EF NIE są bezpieczne dla wątków. Umieszczenie ich w obiekcie statycznym ostatecznie spowoduje błąd „czytnika danych” w odpowiednich warunkach.

Moje pierwotne założenie było takie, że utworzenie tylko jednej instancji obiektu byłoby bardziej wydajne i zapewniłoby lepsze zarządzanie pamięcią. Z tego, co zebrałem, badając ten problem, tak nie jest. W rzeczywistości wydaje się, że bardziej efektywne jest traktowanie każdego wywołania interfejsu API jako izolowanego, bezpiecznego dla wątków zdarzenia. Zapewnienie prawidłowego zwolnienia wszystkich zasobów, gdy obiekt wykracza poza zakres.

Ma to sens zwłaszcza, jeśli przejdziesz do następnego naturalnego postępu API, który polegałby na ujawnieniu go jako WebService lub REST API.

Ujawnienie

• System operacyjny: Windows Server 2012
• .NET: Zainstalowano 4.5, Projektuj przy użyciu 4.0
• Źródło danych: MySQL
• Struktura aplikacji: MVC3
• Uwierzytelnianie: formularze

Zauważyłem, że ten błąd występuje, gdy wysyłam IQueriable do widoku i używam go w podwójnym foreach, gdzie wewnętrzny foreach również musi korzystać z połączenia. Prosty przykład (ViewBag.parents może być IQueriable lub DbSet):

foreach (var parent in ViewBag.parents)
{
    foreach (var child in parent.childs)
    {

    }
}

Najprostszym rozwiązaniem jest użycie .ToList()tej kolekcji przed użyciem. Zauważ też, że MARS nie działa z MySQL.

Odkryłem, że mam ten sam błąd i wystąpił, gdy użyłem Func<TEntity, bool>zamiast zamiast Expression<Func<TEntity, bool>>dla twojego predicate.

Raz zmieniło się wszystko Func's, aby Expression'swyjątkiem przestał wyrzucane.

Wierzę, że EntityFramworkrobi to pewne sprytne rzeczy, z Expression'sktórymi po prostu nie ma nic wspólnegoFunc's

2 rozwiązania mające na celu złagodzenie tego problemu:

1. Wymuś buforowanie pamięci, utrzymując leniwe ładowanie .ToList() po zapytaniu, dzięki czemu możesz iterować przez niego otwierając nowy czytnik danych.
2. .Include(/ dodatkowe encje, które chcesz załadować w zapytaniu /) nazywa się to chętnym ładowaniem, co pozwala (rzeczywiście) dołączyć powiązane obiekty (encje) podczas wykonywania zapytania za pomocą DataReadera.

Dobrym pośrednikiem między włączeniem MARS a pobraniem całego zestawu wyników do pamięci jest pobranie tylko identyfikatorów w początkowym zapytaniu, a następnie przechodzenie przez identyfikatory materializujące każdą jednostkę w trakcie podróży.

Na przykład (używając przykładowych encji „Blog i posty” jak w tej odpowiedzi ):

using (var context = new BlogContext())
{
    // Get the IDs of all the items to loop through. This is
    // materialized so that the data reader is closed by the
    // time we're looping through the list.
    var blogIds = context.Blogs.Select(blog => blog.Id).ToList();

    // This query represents all our items in their full glory,
    // but, items are only materialized one at a time as we
    // loop through them.
    var blogs =
        blogIds.Select(id => context.Blogs.First(blog => blog.Id == id));

    foreach (var blog in blogs)
    {
        this.DoSomethingWith(blog.Posts);

        context.SaveChanges();
    }
}

Oznacza to, że wciąga się do pamięci tylko kilka tysięcy liczb całkowitych, w przeciwieństwie do tysięcy całych wykresów obiektowych, co powinno zminimalizować zużycie pamięci, umożliwiając jednocześnie pracę element po elemencie bez włączania MARS.

Inną zaletą tego, jak widać w przykładzie, jest to, że można zapisywać zmiany podczas przechodzenia przez każdy element, zamiast czekać na koniec pętli (lub inne tego rodzaju obejście), co byłoby potrzebne nawet przy MARS włączony (patrz tutaj i tutaj ).

W moim przypadku stwierdziłem, że przed wywołaniami myContext.SaveChangesAsync () brakowało instrukcji „czekaj”. Dodanie opcji oczekiwania przed tymi wywołaniami asynchronicznymi naprawiło dla mnie problemy z czytnikiem danych.

Jeśli spróbujemy zgrupować część naszych warunków w Func <> lub metodzie rozszerzenia, otrzymamy ten błąd, załóżmy, że mamy taki kod:

public static Func<PriceList, bool> IsCurrent()
{
  return p => (p.ValidFrom == null || p.ValidFrom <= DateTime.Now) &&
              (p.ValidTo == null || p.ValidTo >= DateTime.Now);
}

Or

public static IEnumerable<PriceList> IsCurrent(this IEnumerable<PriceList> prices) { .... }

Spowoduje to wyrzucenie wyjątku, jeśli spróbujemy użyć go w Where (), zamiast tego powinniśmy zbudować Predicate:

public static Expression<Func<PriceList, bool>> IsCurrent()
{
    return p => (p.ValidFrom == null || p.ValidFrom <= DateTime.Now) &&
                (p.ValidTo == null || p.ValidTo >= DateTime.Now);
}

Więcej informacji można znaleźć na stronie : http://www.albahari.com/nutshell/predicatebuilder.aspx

Problem ten można rozwiązać, po prostu przekształcając dane w listę

 var details = _webcontext.products.ToList();


            if (details != null)
            {
                Parallel.ForEach(details, x =>
                {
                    Products obj = new Products();
                    obj.slno = x.slno;
                    obj.ProductName = x.ProductName;
                    obj.Price = Convert.ToInt32(x.Price);
                    li.Add(obj);

                });
                return li;
            }

W mojej sytuacji problem wystąpił z powodu rejestracji wstrzyknięcia zależności. Wstrzykiwałem usługę zakresu na żądanie, która używała dbcontext do zarejestrowanej usługi singleton. W związku z tym kontekst db db został użyty w ramach wielu żądań i stąd błąd.

W moim przypadku problem nie miał nic wspólnego z ciągiem połączenia MARS, ale z serializacją json. Po uaktualnieniu mojego projektu z NetCore2 do 3 dostałem ten błąd.

Więcej informacji można znaleźć tutaj

Rozwiązałem ten problem, używając następującej sekcji kodu przed drugim zapytaniem:

 ...first query
 while (_dbContext.Connection.State != System.Data.ConnectionState.Closed)
 {
     System.Threading.Thread.Sleep(500);
 }
 ...second query

możesz zmienić czas snu w milisekundach

PD Przydatne podczas używania wątków