SqlException da Entity Framework: la nuova transazione non è consentita perché nella sessione sono in esecuzione altri thread

Attualmente sto ricevendo questo errore:

System.Data.SqlClient.SqlException: la nuova transazione non è consentita perché nella sessione sono in esecuzione altri thread.

durante l'esecuzione di questo codice:

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

Modello n. 1: questo modello si trova in un database sul nostro Dev Server. Modello n. 1 http://content.screencast.com/users/Keith.Barrows/folders/Jing/media/bdb2b000-6e60-4af0-a7a1-2bb6b05d8bc1/Model1.png

Modello n. 2: questo modello si trova in un database sul nostro server di produzione e viene aggiornato ogni giorno da feed automatici. testo alternativo http://content.screencast.com/users/Keith.Barrows/folders/Jing/media/4260259f-bce6-43d5-9d2a-017bd9a980d4/Model2.png

Nota: gli elementi cerchiati in rosso nel Modello n. 1 sono i campi che utilizzo per "mappare" sul Modello n. 2. Si prega di ignorare i cerchi rossi nel Modello n. 2: quello è da un'altra domanda che ho avuto a cui ora viene data una risposta.

Nota: devo ancora inserire un controllo isDeleted in modo da poterlo eliminare delicatamente da DB1 se è uscito dall'inventario dei nostri clienti.

Tutto ciò che voglio fare, con questo particolare codice, è connettere un'azienda in DB1 con un client in DB2, ottenere il loro elenco di prodotti da DB2 e INSERIRLO in DB1 se non è già presente. La prima volta dovrebbe essere una vera attrazione dell'inventario. Ogni volta che viene eseguito lì dopo che non dovrebbe accadere nulla a meno che non sia arrivato nuovo inventario nel feed durante la notte.

Quindi la grande domanda: come posso risolvere l'errore di transazione che sto ricevendo? Devo abbandonare e ricreare il mio contesto ogni volta attraverso i loop (non ha senso per me)?

Dopo aver tolto molto i capelli ho scoperto che i foreachcappi erano i colpevoli. Ciò che deve accadere è chiamare EF ma riportarlo in uno IList<T>di quel tipo di destinazione, quindi fare un ciclo sul IList<T>.

Esempio:

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

Come hai già identificato, non puoi salvare da un oggetto foreachche sta ancora attingendo dal database tramite un lettore attivo.

Chiamare ToList()o ToArray()va bene per piccoli set di dati, ma quando hai migliaia di righe, consumerai una grande quantità di memoria.

È meglio caricare le righe in blocchi.

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

Dati i metodi di estensione sopra, puoi scrivere la tua query in questo modo:

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

È necessario ordinare l'oggetto interrogabile su cui si chiama questo metodo. Questo perché Entity Framework supporta solo le IQueryable<T>.Skip(int)query ordinate, il che ha senso se si considera che più query per intervalli diversi richiedono che l'ordinamento sia stabile. Se l'ordinamento non è importante per te, basta ordinare per chiave primaria in quanto è probabile che abbia un indice cluster.

Questa versione interrogherà il database in batch di 100. Si noti che SaveChanges()viene chiamato per ogni entità.

Se vuoi migliorare drasticamente il tuo rendimento, dovresti chiamare SaveChanges()meno frequentemente. Usa invece il codice in questo modo:

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

Ciò comporta 100 volte meno chiamate di aggiornamento del database. Ovviamente ognuna di quelle chiamate richiede più tempo per essere completata, ma alla fine si esce comunque molto avanti. Il tuo chilometraggio può variare, ma per me i mondi sono stati più veloci.

E aggira l'eccezione che stavi vedendo.

EDIT Ho rivisitato questa domanda dopo aver eseguito SQL Profiler e ho aggiornato alcune cose per migliorare le prestazioni. Per chiunque sia interessato, ecco alcuni esempi di SQL che mostrano ciò che viene creato dal DB.

Il primo ciclo non ha bisogno di saltare nulla, quindi è più semplice.

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

Le chiamate successive devono saltare blocchi di risultati precedenti, quindi introduce l'uso di 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

Ora abbiamo pubblicato una risposta ufficiale al bug aperto su Connect . Le soluzioni alternative che consigliamo sono le seguenti:

Questo errore è dovuto al fatto che Entity Framework crea una transazione implicita durante la chiamata SaveChanges (). Il modo migliore per aggirare l'errore consiste nell'utilizzare un modello diverso (ovvero, non salvare durante la lettura) o dichiarare esplicitamente una transazione. Ecco tre possibili soluzioni:

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

In effetti non è possibile salvare le modifiche all'interno di un foreachciclo in C # utilizzando Entity Framework.

context.SaveChanges() Il metodo si comporta come un commit su un normale sistema di database (RDMS).

Apporta tutte le modifiche (che Entity Framework memorizzerà nella cache) e poi salvale tutte in una volta chiamando SaveChanges()dopo il ciclo (al di fuori di esso), come un comando di commit del database.

Funziona se puoi salvare tutte le modifiche contemporaneamente.

context.SaveChanges()Metti solo dopo la fine del tuo foreach(loop).

Usa sempre la tua selezione come Elenco

Per esempio:

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

Quindi scorrere la raccolta mentre si salvano le modifiche

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

             }

Cordiali saluti: da un libro e alcune righe adattate perché il suo stil valido:

Il richiamo del metodo SaveChanges () avvia una transazione che ripristina automaticamente tutte le modifiche persistenti al database se si verifica un'eccezione prima del completamento dell'iterazione; altrimenti la transazione si impegna. Potresti essere tentato di applicare il metodo dopo ogni aggiornamento o eliminazione di un'entità anziché dopo il completamento dell'iterazione, in particolare quando aggiorni o elimini un numero enorme di entità.

Se si tenta di invocare SaveChanges () prima che tutti i dati siano stati elaborati, si incorre in un'eccezione "Nuova transazione non consentita perché ci sono altri thread in esecuzione nella sessione". L'eccezione si verifica perché SQL Server non consente l'avvio di una nuova transazione su una connessione con SqlDataReader aperto, anche con MARS (Multiple Active Record Set) abilitato dalla stringa di connessione (la stringa di connessione predefinita di EF abilita MARS)

A volte è meglio capire perché le cose stanno accadendo ;-)

Rendere i tuoi elenchi interrogabili su .ToList () e dovrebbe funzionare correttamente.

Stavo riscontrando lo stesso problema ma in una situazione diversa. Avevo un elenco di elementi in una casella di riepilogo. L'utente può fare clic su un elemento e selezionare Elimina, ma sto usando un proc memorizzato per eliminare l'elemento perché c'è molta logica coinvolta nell'eliminazione dell'elemento. Quando chiamo il proc memorizzato, l'eliminazione funziona correttamente ma qualsiasi chiamata futura a SaveChanges causerà l'errore. La mia soluzione era chiamare il proc memorizzato al di fuori di EF e questo ha funzionato bene. Per qualche ragione quando chiamo il proc memorizzato usando il modo EF di fare le cose lascia qualcosa di aperto.

Ecco altre 2 opzioni che ti consentono di invocare SaveChanges () in a per ogni ciclo.

La prima opzione è utilizzare un DBContext per generare gli oggetti elenco per scorrere, quindi creare un secondo DBContext per chiamare SaveChanges (). Ecco un esempio:

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

La seconda opzione è quella di ottenere un elenco di oggetti di database da DBContext, ma di selezionare solo gli ID. E quindi scorrere l'elenco degli ID (presumibilmente un int) e ottenere l'oggetto corrispondente a ciascun int e invocare SaveChanges () in quel modo. L'idea alla base di questo metodo è quella di afferrare un ampio elenco di numeri interi, è molto più efficiente quindi ottenere un ampio elenco di oggetti db e chiamare .ToList () sull'intero oggetto. Ecco un esempio di questo metodo:

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

Se ricevi questo errore a causa di foreach e devi davvero salvare prima un'entità all'interno del ciclo e utilizzare l'identità generata più avanti nel ciclo, come nel mio caso, la soluzione più semplice è utilizzare un altro DBContext per inserire un'entità che restituirà Id e userà questo ID nel contesto esterno

Per esempio

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

Quindi nel progetto ho avuto lo stesso identico problema che il problema non riguardava foreacho .toList()era effettivamente nella configurazione AutoFac che abbiamo usato. Ciò ha creato alcune situazioni strane in cui è stato generato l'errore sopra riportato ma sono stati anche lanciati un sacco di altri errori equivalenti.

Questa era la nostra soluzione: cambiato questo:

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

Per:

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

So che è una vecchia domanda, ma oggi ho riscontrato questo errore.

e ho scoperto che, questo errore può essere generato quando un trigger di tabella del database ottiene un errore.

per tua informazione, puoi controllare anche i trigger delle tue tabelle quando ricevi questo errore.

Avevo bisogno di leggere un enorme ResultSet e aggiornare alcuni record nella tabella. Ho cercato di usare pezzi come suggerito nel Drew Noakes 's risposta .

Purtroppo dopo 50000 dischi ho OutofMemoryException. La risposta spiega: Entity framework data set di grandi dimensioni, eccezione di memoria esaurita

EF crea una seconda copia di dati che utilizza per il rilevamento delle modifiche (in modo che possa persistere modifiche al database). EF contiene questo secondo set per la durata del contesto ed è questo set che ti sta esaurendo la memoria.

La raccomandazione è di ricreare il contesto per ciascun batch.

Quindi ho recuperato i valori Minimo e Massimo della chiave primaria: le tabelle hanno le chiavi primarie come interi incrementali automatici, quindi ho recuperato dai blocchi di database dei record aprendo il contesto per ogni blocco. Dopo l'elaborazione, il contesto del blocco si chiude e rilascia la memoria. Assicura che l'utilizzo della memoria non sta crescendo.

Di seguito è riportato uno snippet dal mio codice:

  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 è una struttura semplice con proprietà From e To.

Abbiamo iniziato a vedere questo errore "Nuova transazione non consentita perché nella sessione sono in esecuzione altri thread" dopo la migrazione da EF5 a EF6.

Google ci ha portato qui ma non stiamo chiamando SaveChanges()all'interno del loop. Gli errori sono stati generati durante l'esecuzione di una procedura memorizzata utilizzando ObjectContext.ExecuteFunction all'interno di un ciclo foreach che legge dal DB.

Qualsiasi chiamata a ObjectContext.ExecuteFunction avvolge la funzione in una transazione. L'inizio di una transazione mentre è già presente un lettore aperto causa l'errore.

È possibile disabilitare il wrapping dell'SP in una transazione impostando la seguente opzione.

_context.Configuration.EnsureTransactionsForFunctionsAndCommands = false;

L' EnsureTransactionsForFunctionsAndCommandsopzione consente l'esecuzione dell'SP senza creare la propria transazione e l'errore non viene più generato.

Proprietà DbContextConfiguration.EnsureTransactionsForFunctionsAndCommands

Stavo anche affrontando lo stesso problema.

Ecco la causa e la soluzione.

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

Assicurati prima di lanciare comandi di manipolazione dei dati come inserti, aggiornamenti, hai chiuso tutti i precedenti lettori SQL attivi.

L'errore più comune sono le funzioni che leggono i dati da db e restituiscono valori. Ad esempio funzioni come isRecordExist.

In questo caso torniamo immediatamente dalla funzione se abbiamo trovato il record e dimentichiamo di chiudere il lettore.

Il codice qui sotto funziona per me:

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

Nel mio caso, il problema è apparso quando ho chiamato Stored Procedure tramite EF e successivamente SaveChanges ha lanciato questa eccezione. Il problema era nel chiamare la procedura, l'enumeratore non era disposto. Ho corretto il codice nel modo seguente:

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

Sono in ritardo alla festa, ma oggi ho riscontrato lo stesso errore e il modo in cui ho risolto era semplice. Il mio scenario era simile a questo codice dato che stavo facendo transazioni DB all'interno di cicli annidati per ogni.

Il problema è che una transazione DB singola impiega un po 'più di tempo rispetto al ciclo for-each, quindi una volta che la transazione precedente non è completa, la nuova trazione genera un'eccezione, quindi la soluzione è creare un nuovo oggetto nel ciclo for-each dove stai effettuando una transazione db.

Per gli scenari sopra menzionati la soluzione sarà così:

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 ### //
                    }
                }

Sono un po 'in ritardo, ma ho avuto anche questo errore. Ho risolto il problema controllando quali sono i valori che sono stati aggiornati.

Ho scoperto che la mia query era errata e che lì erano in sospeso oltre 250 modifiche. Quindi ho corretto la mia query e ora funziona correttamente.

Quindi, nella mia situazione: controllare la query per errori, eseguendo il debug sul risultato restituito dalla query. Dopodiché correggi la query.

Spero che questo aiuti a risolvere i problemi futuri.