Entity Framework: вже є відкритий DataReader, пов'язаний з цією командою

Я використовую Entity Framework і час від часу я отримуватиму цю помилку.

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

Навіть не дивлячись на те, що я не займаюся ручним управлінням з'єднаннями.

ця помилка трапляється з перервами.

код, який запускає помилку (скорочується для зручності читання):

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

використовуючи шаблон розпорядження, щоб кожен раз відкривати нове з'єднання.

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());
    }

}

все ще проблематично

чому EF не використовуватиме повторно з'єднання, якщо воно вже відкрите.

Йдеться не про закриття з'єднання. EF правильно керує з'єднанням. Моє розуміння цієї проблеми полягає в тому, що існує кілька команд пошуку даних, які виконуються на одному з'єднанні (або одна команда з декількома виборами), тоді як наступний DataReader виконується до того, як перше завершило читання. Єдиний спосіб уникнути винятку - дозволити кілька вкладених DataReaders = увімкнути MultipleActiveResultSets. Інший сценарій, коли це завжди відбувається, це коли ви повторюєте результат запиту (IQueryable), і ви запускаєте ледаче завантаження для завантаженого об'єкта всередині ітерації.

Як варіант використання MARS (MultipleActiveResultSets), ви можете написати свій код, щоб не відкривати кілька наборів результатів.

Що ви можете зробити - це відновити дані в пам'ять, і таким чином у вас не буде відкритого читача. Часто це викликано ітерацією через набір результатів при спробі відкрити інший набір результатів.

Приклад коду:

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; }
}

Скажімо, ви робите пошук у вашій базі даних, що містить:

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"));
}

Ми можемо зробити просте рішення для цього, додавши .ToList (), як це:

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

Це змушує підрозділ кадрів завантажувати список у пам'ять, таким чином, коли ми повторюємо, хоча він у циклі foreach вже не використовує зчитувач даних для відкриття списку, він замість цього знаходиться в пам'яті.

Я усвідомлюю, що це може бути не бажаним, якщо ви хочете, наприклад, ліниво завантажити деякі властивості. Це здебільшого приклад, який, сподіваємось, пояснює, як / чому у вас може виникнути ця проблема, щоб ви могли приймати рішення відповідно

Є ще один спосіб подолати цю проблему. Чи буде це кращий спосіб, залежить від вашої ситуації.

Проблема виникає внаслідок ледачого завантаження, тому один із способів уникнути цього - не мати ледачого завантаження, використовуючи Включити:

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

Якщо ви використовуєте відповідні Includes, ви можете уникнути включення MARS. Але якщо ви пропустите її, ви отримаєте помилку, тому включення MARS, мабуть, найпростіший спосіб виправити.

Ви отримуєте цю помилку, коли колекція, яку ви намагаєтесь повторити, є ледачим завантаженням (IQueriable).

foreach (var user in _dbContext.Users)
{    
}

Перетворення колекції IQueriable в іншу численну колекцію вирішить цю проблему. приклад

_dbContext.Users.ToList()

Примітка. .ToList () створює новий набір щоразу, і це може спричинити проблеми з продуктивністю, якщо ви маєте справу з великими даними.

Я вирішив проблему легко (прагматично), додавши в конструктор варіант. Таким чином, я використовую це лише за потреби.

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

Спробуйте в своєму рядку з'єднання встановити MultipleActiveResultSets=true. Це дозволяє багатозадачність на базі даних.

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

Це працює для мене ... будь то ваш зв’язок у app.config чи ви встановили це програмно ... сподіваюся, це корисне

Спочатку я вирішив використовувати статичне поле в своєму класі API для посилання на екземпляр об’єкта MyDataContext (де MyDataContext є об'єктом контексту EF5), але саме це, здавалося, створило проблему. Я додав код на зразок наступного до кожного мого методу API, і це вирішило проблему.

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

Як заявили інші люди, об'єкти контексту даних EF НЕ безпечні для потоків. Тож розміщення їх у статичному об’єкті врешті призведе до помилки «зчитувача даних» за правильних умов.

Моє первісне припущення полягало в тому, що створення лише одного примірника об'єкта було б ефективнішим і дозволяло б краще керувати пам'яттю. З того, що я зібрав, досліджуючи це питання, це не так. Насправді, здається, більш ефективно ставитись до кожного дзвінка до вашого API як до події, що є безпечною для потоків. Забезпечення належного звільнення всіх ресурсів, оскільки об’єкт виходить із сфери застосування.

Це має сенс особливо, якщо ви перейдете на свій API до наступного природного прогресу, який би піддавав його як WebService або REST API.

Розкриття інформації

• ОС: Windows Server 2012
• .NET: Встановлено 4.5, проект за допомогою 4.0
• Джерело даних: MySQL
• Застосування програми: MVC3
• Автентифікація: форми

Я помітив, що ця помилка трапляється, коли я надсилаю IQueriable до представлення даних і використовую його в подвійному передбаченні, де внутрішній foreach також повинен використовувати з'єднання. Простий приклад (ViewBag.parents може бути IQueriable або DbSet):

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

    }
}

Просте рішення - використовувати .ToList()в колекції перед її використанням. Також зауважте, що MARS не працює з MySQL.

Я виявив, що у мене така ж помилка, і вона сталася, коли я використовував Func<TEntity, bool>замість Expression<Func<TEntity, bool>>вашого для вашого predicate.

Як тільки я змінив усіх, Func'sщоб Expression'sвиняток перестав кидати.

Я вважаю, що EntityFramworkце робить якісь розумні речі, з Expression'sякими він просто не робитьFunc's

2 рішення для усунення цієї проблеми:

1. Примушуйте кешування пам’яті зберігати ледачий завантаження .ToList()після запиту, тож ви зможете повторити його, відкривши новий DataReader.
2. .Include(/ додаткові об'єкти, які ви хочете завантажити в запиті /) це називається нетерплячим завантаженням, яке дозволяє (дійсно) включати пов'язані об'єкти (сутності) під час виконання запиту з DataReader.

Хороший середина між включенням MARS та завантаженням всього набору результатів у пам'ять - це отримати лише ідентифікатори в початковому запиті, а потім проглянути цикл ідентифікаторів, що матеріалізують кожну сутність, коли ви йдете.

Наприклад (використовуючи зразки "Блог і пости", як у цій відповіді ):

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();
    }
}

Це означає, що ви втягуєте в пам'ять лише кілька тисяч цілих чисел, на відміну від тисяч цілих графіків об'єктів, які повинні мінімізувати використання пам'яті, дозволяючи вам працювати по окремих пунктах без включення MARS.

Ще одна приємна перевага цього, як видно з зразка, полягає в тому, що ви можете зберігати зміни під час перегляду циклу кожного елемента, замість того, щоб чекати до кінця циклу (або якогось іншого такого способу), як це було б потрібно навіть для MARS увімкнено (див. Тут і тут ).

У моєму випадку я виявив, що перед викликами myContext.SaveChangesAsync () були відсутні "заяви очікування". Додавання очікування перед тими викликами асинхронізації вирішило для мене проблеми з читанням даних.

Якщо ми спробуємо згрупувати частину наших умов у метод Func <> або розширення, ми отримаємо цю помилку, припустимо, у нас такий код:

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) { .... }

Це викине виняток, якщо ми спробуємо використовувати його у Where (), що замість цього ми повинні зробити, це створити предикат так:

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

Детальніше можна прочитати на веб-сайті : http://www.albahari.com/nutshell/predicatebuilder.aspx

Цю проблему можна вирішити просто шляхом перетворення даних у список

 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;
            }

У моїй ситуації проблема виникла через реєстрацію ін'єкційної залежності. Я вводив службу на замовлення на запит, яка використовувала dbcontext, в послугу, зареєстровану одиночку. Для цього dbcontext використовувався в межах декількох запитів, а отже, і помилка.

У моєму випадку проблема не мала нічого спільного з рядком з'єднання MARS, а з серіалізацією json. Після оновлення мого проекту з NetCore2 до 3 я отримав цю помилку.

Більше інформації можна знайти тут

Цю проблему я вирішив за допомогою наступного розділу коду перед другим запитом:

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

ви можете змінити час сну в мілісекундах

PD Корисний при використанні ниток