SqlException від Entity Framework - Нова транзакція не дозволена, оскільки в сеансі працюють інші потоки

Зараз я отримую цю помилку:

System.Data.SqlClient.SqlException: Нова транзакція заборонена, оскільки в сеансі працюють інші потоки.

під час виконання цього коду:

public class ProductManager : IProductManager
{
    #region Declare Models
    private RivWorks.Model.Negotiation.RIV_Entities _dbRiv = RivWorks.Model.Stores.RivEntities(AppSettings.RivWorkEntities_connString);
    private RivWorks.Model.NegotiationAutos.RivFeedsEntities _dbFeed = RivWorks.Model.Stores.FeedEntities(AppSettings.FeedAutosEntities_connString);
    #endregion

    public IProduct GetProductById(Guid productId)
    {
        // Do a quick sync of the feeds...
        SyncFeeds();
        ...
        // get a product...
        ...
        return product;
    }

    private void SyncFeeds()
    {
        bool found = false;
        string feedSource = "AUTO";
        switch (feedSource) // companyFeedDetail.FeedSourceTable.ToUpper())
        {
            case "AUTO":
                var clientList = from a in _dbFeed.Client.Include("Auto") select a;
                foreach (RivWorks.Model.NegotiationAutos.Client client in clientList)
                {
                    var companyFeedDetailList = from a in _dbRiv.AutoNegotiationDetails where a.ClientID == client.ClientID select a;
                    foreach (RivWorks.Model.Negotiation.AutoNegotiationDetails companyFeedDetail in companyFeedDetailList)
                    {
                        if (companyFeedDetail.FeedSourceTable.ToUpper() == "AUTO")
                        {
                            var company = (from a in _dbRiv.Company.Include("Product") where a.CompanyId == companyFeedDetail.CompanyId select a).First();
                            foreach (RivWorks.Model.NegotiationAutos.Auto sourceProduct in client.Auto)
                            {
                                foreach (RivWorks.Model.Negotiation.Product targetProduct in company.Product)
                                {
                                    if (targetProduct.alternateProductID == sourceProduct.AutoID)
                                    {
                                        found = true;
                                        break;
                                    }
                                }
                                if (!found)
                                {
                                    var newProduct = new RivWorks.Model.Negotiation.Product();
                                    newProduct.alternateProductID = sourceProduct.AutoID;
                                    newProduct.isFromFeed = true;
                                    newProduct.isDeleted = false;
                                    newProduct.SKU = sourceProduct.StockNumber;
                                    company.Product.Add(newProduct);
                                }
                            }
                            _dbRiv.SaveChanges();  // ### THIS BREAKS ### //
                        }
                    }
                }
                break;
        }
    }
}

Модель №1 - Ця модель знаходиться в базі даних на нашому Dev Server. Модель №1 http://content.screencast.com/users/Keith.Barrows/folders/Jing/media/bdb2b000-6e60-4af0-a7a1-2bb6b05d8bc1/Model1.png

Модель №2 - Ця модель знаходиться в базі даних на нашому сервері Prod і оновлюється щодня автоматичними каналами. alt text http://content.screencast.com/users/Keith.Barrows/folders/Jing/media/4260259f-bce6-43d5-9d2a-017bd9a980d4/Model2.png

Примітка. Червоні обведені елементи в моделі №1 - це поля, які я використовую для "відображення" в моделі №2. Будь ласка, ігноруйте червоні кола в моделі №2: це інше питання, на яке я зараз відповів.

Примітка. Мені все ж потрібно поставити чек isDeleted, щоб я міг видалити його з DB1, якщо він вийшов з інвентарю нашого клієнта.

Все, що я хочу зробити, за допомогою цього конкретного коду - це з'єднати компанію в DB1 з клієнтом у DB2, отримати їх список продуктів від DB2 та ВСТУПИТИ його в DB1, якщо його ще немає. Перший час через це має бути повне витяг товарних запасів. Кожен раз, коли він запускається там, після цього нічого не повинно відбуватися, якщо нові номери не надходили протягом ночі.

Отже, велике запитання - як вирішити помилку транзакції, яку я отримую? Чи потрібно мені скидати та відтворювати свій контекст кожен раз через петлі (це не має для мене сенсу)?

Після довгого витягування волосся я виявив, що foreachвинуватцями є петлі. Що повинно відбутися, це викликати EF, але повернути його в IList<T>цільовий тип, а потім цикл на IList<T>.

Приклад:

IList<Client> clientList = from a in _dbFeed.Client.Include("Auto") select a;
foreach (RivWorks.Model.NegotiationAutos.Client client in clientList)
{
   var companyFeedDetailList = from a in _dbRiv.AutoNegotiationDetails where a.ClientID == client.ClientID select a;
    // ...
}

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

Дзвінки ToList()або ToArray()добре для невеликих наборів даних, але коли у вас є тисячі рядків, ви будете витрачати велику кількість пам'яті.

Рядки краще завантажувати шматками.

public static class EntityFrameworkUtil
{
    public static IEnumerable<T> QueryInChunksOf<T>(this IQueryable<T> queryable, int chunkSize)
    {
        return queryable.QueryChunksOfSize(chunkSize).SelectMany(chunk => chunk);
    }

    public static IEnumerable<T[]> QueryChunksOfSize<T>(this IQueryable<T> queryable, int chunkSize)
    {
        int chunkNumber = 0;
        while (true)
        {
            var query = (chunkNumber == 0)
                ? queryable 
                : queryable.Skip(chunkNumber * chunkSize);
            var chunk = query.Take(chunkSize).ToArray();
            if (chunk.Length == 0)
                yield break;
            yield return chunk;
            chunkNumber++;
        }
    }
}

Враховуючи наведені вище методи розширення, ви можете написати свій запит так:

foreach (var client in clientList.OrderBy(c => c.Id).QueryInChunksOf(100))
{
    // do stuff
    context.SaveChanges();
}

Об'єкт, що запитує, на який ви викликаєте цей метод, повинен бути замовлений. Це тому, що Entity Framework підтримує лише IQueryable<T>.Skip(int)замовлені запити, що має сенс, якщо ви вважаєте, що кілька запитів для різних діапазонів вимагають, щоб замовлення було стабільним. Якщо замовлення для вас не важливе, просто замовляйте за первинним ключем, оскільки це, ймовірно, має кластерний індекс.

Ця версія запитує базу даних в партіях по 100. Зверніть увагу, що SaveChanges()викликається для кожної сутності.

Якщо ви хочете значно покращити пропускну здатність, вам слід дзвонити SaveChanges()рідше. Використовуйте такий код замість цього:

foreach (var chunk in clientList.OrderBy(c => c.Id).QueryChunksOfSize(100))
{
    foreach (var client in chunk)
    {
        // do stuff
    }
    context.SaveChanges();
}

Це призводить до в 100 разів менших викликів оновлення бази даних. Звичайно, кожен із цих дзвінків займає більше часу, але ви все-таки вийдете вперед. Ваш пробіг може відрізнятися, але це було світами швидше для мене.

І це оточує виняток, який ви бачили.

EDIT Я переглянув це питання після запуску SQL Profiler і оновив кілька речей для підвищення продуктивності. Для всіх, хто цікавиться, ось деякий зразок SQL, який показує, що створюється БД.

Перший цикл нічого не потрібно пропускати, так це простіше.

SELECT TOP (100)                     -- the chunk size 
[Extent1].[Id] AS [Id], 
[Extent1].[Name] AS [Name], 
FROM [dbo].[Clients] AS [Extent1]
ORDER BY [Extent1].[Id] ASC

Подальші дзвінки повинні пропустити попередні фрагменти результатів, тому вводиться використання row_number:

SELECT TOP (100)                     -- the chunk size
[Extent1].[Id] AS [Id], 
[Extent1].[Name] AS [Name], 
FROM (
    SELECT [Extent1].[Id] AS [Id], [Extent1].[Name] AS [Name], row_number()
    OVER (ORDER BY [Extent1].[Id] ASC) AS [row_number]
    FROM [dbo].[Clients] AS [Extent1]
) AS [Extent1]
WHERE [Extent1].[row_number] > 100   -- the number of rows to skip
ORDER BY [Extent1].[Id] ASC

Зараз ми опублікували офіційну відповідь на помилку, відкриту на Connect . Ми вирішуємо наступні способи вирішення:

Ця помилка пов’язана з тим, що Entity Framework створює неявну транзакцію під час виклику SaveChanges (). Найкращий спосіб подолати помилку - це використовувати інший зразок (тобто не економити в розпалі читання) або чітко оголосивши транзакцію. Ось три можливі рішення:

// 1: Save after iteration (recommended approach in most cases)
using (var context = new MyContext())
{
    foreach (var person in context.People)
    {
        // Change to person
    }
    context.SaveChanges();
}

// 2: Declare an explicit transaction
using (var transaction = new TransactionScope())
{
    using (var context = new MyContext())
    {
        foreach (var person in context.People)
        {
            // Change to person
            context.SaveChanges();
        }
    }
    transaction.Complete();
}

// 3: Read rows ahead (Dangerous!)
using (var context = new MyContext())
{
    var people = context.People.ToList(); // Note that this forces the database
                                          // to evaluate the query immediately
                                          // and could be very bad for large tables.

    foreach (var person in people)
    {
        // Change to person
        context.SaveChanges();
    }
} 

Дійсно, ви не можете зберегти зміни всередині foreachциклу в C # за допомогою Entity Framework.

context.SaveChanges() метод діє як фіксація в звичайній системі баз даних (RDMS).

Просто внесіть усі зміни (який Entity Framework буде кешувати), а потім збережіть їх усі відразу, викликаючи SaveChanges()цикл (поза ним), як команда фіксації бази даних.

Це працює, якщо ви можете зберегти всі зміни одразу.

Просто кладіть context.SaveChanges()після закінчення foreach(цикл).

Завжди використовуйте свій вибір як Список

Наприклад:

var tempGroupOfFiles = Entities.Submited_Files.Where(r => r.FileStatusID == 10 && r.EventID == EventId).ToList();

Потім прокрутіть колекцію, зберігаючи зміни

 foreach (var item in tempGroupOfFiles)
             {
                 var itemToUpdate = item;
                 if (itemToUpdate != null)
                 {
                     itemToUpdate.FileStatusID = 8;
                     itemToUpdate.LastModifiedDate = DateTime.Now;
                 }
                 Entities.SaveChanges();

             }

FYI: з книги та деяких рядків скориговано, тому що її стиль дійсний:

Метод виклику SaveChanges () починає транзакцію, яка автоматично відкочує всі зміни, що зберігаються в базі даних, якщо виняток виникає до завершення ітерації; інакше транзакція вчиняється. Ви можете спокуситись застосувати метод після кожного оновлення чи видалення об'єкта, а не після завершення ітерації, особливо коли ви оновлюєте чи видаляєте величезну кількість сутностей.

Якщо ви спробуєте викликати SaveChanges () перед тим, як всі дані будуть оброблені, ви зробите виняток "Нова транзакція заборонена, оскільки в сеансі працюють інші потоки". Виняток виникає через те, що SQL Server не дозволяє запускати нову транзакцію на з’єднанні, у якому відкритий SqlDataReader, навіть якщо декілька активних наборів запису (MARS) увімкнено рядком з'єднання (рядок підключення за замовчуванням EF дозволяє MARS)

Іноді краще зрозуміти, чому все відбувається ;-)

Створення списків, що підлягають запиту, до .ToList (), і це повинно працювати нормально.

Я отримував цю ж проблему, але в іншій ситуації. У списку я мав список елементів. Користувач може натиснути елемент і вибрати видалити, але для видалення елемента я використовую збережену програму, оскільки для видалення елемента є багато логіки. Коли я зателефоную на збережену процедуру, видалення працює нормально, але будь-який майбутній виклик SaveChanges призведе до помилки. Моє рішення полягало в тому, щоб зателефонувати на збережений процесор поза EF, і це спрацювало чудово. З якихось причин, коли я закликаю збережену програму, використовуючи метод EF, це робить щось відкритим.

Ось ще два варіанти, за допомогою яких можна викликати SaveChanges () в а для кожного циклу.

Перший варіант полягає у використанні одного DBContext для генерації об'єктів списку для повторення, а потім створити другий DBContext для виклику SaveChanges (). Ось приклад:

//Get your IQueryable list of objects from your main DBContext(db)    
IQueryable<Object> objects = db.Object.Where(whatever where clause you desire);

//Create a new DBContext outside of the foreach loop    
using (DBContext dbMod = new DBContext())
{   
    //Loop through the IQueryable       
    foreach (Object object in objects)
    {
        //Get the same object you are operating on in the foreach loop from the new DBContext(dbMod) using the objects id           
        Object objectMod = dbMod.Object.Find(object.id);

        //Make whatever changes you need on objectMod
        objectMod.RightNow = DateTime.Now;

        //Invoke SaveChanges() on the dbMod context         
        dbMod.SaveChanges()
    }
}

Другий варіант - отримати список об'єктів бази даних з DBContext, але вибрати лише ідентифікатори. А потім перегляньте список ідентифікаторів (імовірно, int) та отримайте об'єкт, відповідний кожному int, та виклик SaveChanges () таким чином. Ідея цього методу - захопити великий список цілих чисел, набагато ефективніше, ніж отримати великий список об’єктів db та викликати .ToList () на весь об’єкт. Ось приклад цього методу:

//Get the list of objects you want from your DBContext, and select just the Id's and create a list
List<int> Ids = db.Object.Where(enter where clause here)Select(m => m.Id).ToList();

var objects = Ids.Select(id => db.Objects.Find(id));

foreach (var object in objects)
{
    object.RightNow = DateTime.Now;
    db.SaveChanges()
}

Якщо ви отримаєте цю помилку через foreach, і вам дійсно потрібно зберегти одну сутність спочатку всередині циклу та використовувати згенеровану ідентичність далі в циклі, як це було в моєму випадку, найпростішим рішенням є використання іншого DBContext для вставки сутності, яка повертає id та використання це ІД у зовнішньому контексті

Наприклад

    using (var context = new DatabaseContext())
    {
        ...
        using (var context1 = new DatabaseContext())
        {
            ...
               context1.SaveChanges();
        }                         
        //get id of inserted object from context1 and use is.   
      context.SaveChanges();
   }

Тож у проекті, якщо у мене була така сама проблема, проблема не була foreachабо .toList()вона була фактично в налаштуваннях AutoFac, яку ми використовували. Це створило деякі дивні ситуації, коли вищесказана помилка була кинута, але також було кинуто купу інших аналогічних помилок.

Це було нашим виправленням. Змінено це:

container.RegisterType<DataContext>().As<DbContext>().InstancePerLifetimeScope();
container.RegisterType<DbFactory>().As<IDbFactory>().SingleInstance();
container.RegisterType<UnitOfWork>().As<IUnitOfWork>().InstancePerRequest();

До:

container.RegisterType<DataContext>().As<DbContext>().As<DbContext>();
container.RegisterType<DbFactory>().As<IDbFactory>().As<IDbFactory>().InstancePerLifetimeScope();
container.RegisterType<UnitOfWork>().As<IUnitOfWork>().As<IUnitOfWork>();//.InstancePerRequest();

Я знаю, що це старе питання, але я сьогодні зіткнувся з цією помилкою.

і я виявив, що ця помилка може бути викинута, коли тригер таблиці бази даних отримає помилку.

для вашої інформації ви також можете перевірити тригери ваших таблиць, коли отримаєте цю помилку.

Мені потрібно було прочитати величезний ResultSet та оновити деякі записи в таблиці. Я намагався використовувати шматки , як запропоновано в Drew Нокс «и відповідь .

На жаль, після 50000 записів я отримав OutofMemoryException. Великий набір даних відповіді Entity Framework, виняток із пам'яті, пояснює це

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

Рекомендація полягає в тому, щоб заново створити свій контекст для кожної партії.

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

Нижче наведено фрагмент з мого коду:

  public void ProcessContextByChunks ()
  {
        var tableName = "MyTable";
         var startTime = DateTime.Now;
        int i = 0;
         var minMaxIds = GetMinMaxIds();
        for (int fromKeyID= minMaxIds.From; fromKeyID <= minMaxIds.To; fromKeyID = fromKeyID+_chunkSize)
        {
            try
            {
                using (var context = InitContext())
                {   
                    var chunk = GetMyTableQuery(context).Where(r => (r.KeyID >= fromKeyID) && (r.KeyID < fromKeyID+ _chunkSize));
                    try
                    {
                        foreach (var row in chunk)
                        {
                            foundCount = UpdateRowIfNeeded(++i, row);
                        }
                        context.SaveChanges();
                    }
                    catch (Exception exc)
                    {
                        LogChunkException(i, exc);
                    }
                }
            }
            catch (Exception exc)
            {
                LogChunkException(i, exc);
            }
        }
        LogSummaryLine(tableName, i, foundCount, startTime);
    }

    private FromToRange<int> GetminMaxIds()
    {
        var minMaxIds = new FromToRange<int>();
        using (var context = InitContext())
        {
            var allRows = GetMyTableQuery(context);
            minMaxIds.From = allRows.Min(n => (int?)n.KeyID ?? 0);  
            minMaxIds.To = allRows.Max(n => (int?)n.KeyID ?? 0);
        }
        return minMaxIds;
    }

    private IQueryable<MyTable> GetMyTableQuery(MyEFContext context)
    {
        return context.MyTable;
    }

    private  MyEFContext InitContext()
    {
        var context = new MyEFContext();
        context.Database.Connection.ConnectionString = _connectionString;
        //context.Database.Log = SqlLog;
        return context;
    }

FromToRange - це проста структура із властивостями From і To.

Я також стикався з тим же питанням.

Ось причина і рішення.

http://blogs.msdn.com/b/cbiyikoglu/archive/2006/11/21/mars-transaction-and-sql-error-3997-3988-or-3983.aspx

Переконайтесь, що перед запуском таких команд для маніпулювання даними, як вставки, оновлення, ви закрили всі попередні активні зчитувачі SQL.

Найчастіша помилка - це функції, які зчитують дані з db та повертають значення. Наприклад, такі функції, як isRecordExist.

У цьому випадку ми негайно повертаємося з функції, якщо знайшли запис і забули закрити читач.

Код нижче працює для мене:

private pricecheckEntities _context = new pricecheckEntities();

...

private void resetpcheckedtoFalse()
{
    try
    {
        foreach (var product in _context.products)
        {
            product.pchecked = false;
            _context.products.Attach(product);
            _context.Entry(product).State = EntityState.Modified;
        }
        _context.SaveChanges();
    }
    catch (Exception extofException)
    {
        MessageBox.Show(extofException.ToString());

    }
    productsDataGrid.Items.Refresh();
}

У моєму випадку проблема з’явилася, коли я зателефонував до Stored Procedure через EF, а потім пізніше SaveChanges викине цей виняток. Проблема полягала у виклику процедури, перелік не розпоряджався. Я виправив код наступним чином:

public bool IsUserInRole(string username, string roleName, DataContext context)
{          
   var result = context.aspnet_UsersInRoles_IsUserInRoleEF("/", username, roleName);

   //using here solved the issue
   using (var en = result.GetEnumerator()) 
   {
     if (!en.MoveNext())
       throw new Exception("emty result of aspnet_UsersInRoles_IsUserInRoleEF");
     int? resultData = en.Current;

     return resultData == 1;//1 = success, see T-SQL for return codes
   }
}

Ми почали бачити цю помилку "Нова транзакція заборонена, оскільки в сеансі працюють інші потоки" після переходу з EF5 на EF6.

Google привів нас сюди, але ми не дзвонимо SaveChanges() в цикл. Помилки виникали під час виконання збереженої процедури, використовуючи ObjectContext.ExecuteFunction всередині циклу foreach, що читається з БД.

Будь-який виклик до ObjectContext.ExecuteFunction завершує функцію транзакції. Початок транзакції, коли вже є відкритий зчитувач, викликає помилку.

Можна відключити обгортку SP в транзакції, встановивши наступний параметр.

_context.Configuration.EnsureTransactionsForFunctionsAndCommands = false;

EnsureTransactionsForFunctionsAndCommandsОпція дозволяє SP працювати без створення своєї власної транзакції і помилка більше не піднімається.

DbContextConfiguration.EnsureTransactionForFunctionsAndCommands Properties

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

Проблема полягає в тому, що транзакція Single DB займає трохи більше часу, ніж для кожного циклу, тож коли попередня транзакція не завершена, то нова тяга кидає виняток, тому рішення полягає у створенні нового об'єкта в циклі for для кожного де ви здійснюєте транзакцію db.

Для вищезазначених сценаріїв рішення буде таким:

foreach (RivWorks.Model.Negotiation.AutoNegotiationDetails companyFeedDetail in companyFeedDetailList)
                {
private RivWorks.Model.Negotiation.RIV_Entities _dbRiv = RivWorks.Model.Stores.RivEntities(AppSettings.RivWorkEntities_connString);
                    if (companyFeedDetail.FeedSourceTable.ToUpper() == "AUTO")
                    {
                        var company = (from a in _dbRiv.Company.Include("Product") where a.CompanyId == companyFeedDetail.CompanyId select a).First();
                        foreach (RivWorks.Model.NegotiationAutos.Auto sourceProduct in client.Auto)
                        {
                            foreach (RivWorks.Model.Negotiation.Product targetProduct in company.Product)
                            {
                                if (targetProduct.alternateProductID == sourceProduct.AutoID)
                                {
                                    found = true;
                                    break;
                                }
                            }
                            if (!found)
                            {
                                var newProduct = new RivWorks.Model.Negotiation.Product();
                                newProduct.alternateProductID = sourceProduct.AutoID;
                                newProduct.isFromFeed = true;
                                newProduct.isDeleted = false;
                                newProduct.SKU = sourceProduct.StockNumber;
                                company.Product.Add(newProduct);
                            }
                        }
                        _dbRiv.SaveChanges();  // ### THIS BREAKS ### //
                    }
                }

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

Я з’ясував, що мій запит був неправильним і що там понад 250+ редагувань очікують на розгляд. Тому я виправив свій запит, і тепер він працює правильно.

Отже, в моїй ситуації: Перевірте запит на помилки, налагодивши результат, який запит повертає. Після цього виправте запит.

Сподіваюся, що це допомагає вирішити майбутні проблеми.