2013-05-22 16 views
8

Ho il seguente test di unità molto semplice che riproduce un caso in cui DbContext.SaveChanges non è atomico. Per non atomico intendo che i dati impegnati possono essere letti prima che tutto il commit fosse completato.Entity Framework Code First: SaveChanges non è atomico

Aggiungi attività: in un ciclo, aggiunge un nuovo TestEntity e un ReferencingEntity. Convalida attività: verifica se esiste un TestEntity a cui non fa riferimento alcun ReferencingEntity, che non dovrebbe verificarsi a causa del modo in cui aggiungo le entità.

Il test dell'unità fallisce ... qualche consiglio?

EDIT: Secondo la risposta accettata - Al fine di eseguire il test di unità con la soluzione proposta aggiungere nel metodo InitTest:

using (var context = new TestContext()) 
{ 
    var objectContext = (context as IObjectContextAdapter).ObjectContext; 
    objectContext.ExecuteStoreCommand(string.Format("ALTER DATABASE [{0}] SET READ_COMMITTED_SNAPSHOT ON", context.GetType().FullName)); 
} 

prova Unità:

using System.Data.Entity; 
using System.Linq; 
using System.Threading.Tasks; 
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace Atlit.Server.Tests.Integration.SessionProcessing 
{ 
    class TestContext : DbContext 
    { 
     public DbSet<TestEntity> TestEntities { get; set; } 
     public DbSet<ReferencingEntity> ReferencingEntities { get; set; } 
    } 

    class TestEntity 
    { 
     public int TestEntityId { get; set; } 
    } 

    class ReferencingEntity 
    { 
     public int ReferencingEntityId { get; set; } 
     public TestEntity TestEntity { get; set; } 
    } 

    [TestClass] 
    public class SaveChangesAtomicTest 
    { 
     private volatile int m_Count = 3000; 
     private volatile bool m_Failed = false; 

     [TestInitialize] 
     public void InitTest() 
     { 
      using (var context = new TestContext()) 
      { 
       var dbInitializer = new DropCreateDatabaseAlways<TestContext>(); 
       dbInitializer.InitializeDatabase(context); 
      } 
     } 

     private void AddEntities() 
     { 
      while (m_Count-- > 0 && !m_Failed) 
      { 
       var transactionOptions = new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }; 
       using (var transactionScope = new TransactionScope(TransactionScopeOption.RequiresNew, transactionOptions)) 
       { 
        using (var context = new TestContext()) 
        { 
         var entity = context.TestEntities.Add(new TestEntity()); 
         context.ReferencingEntities.Add(new ReferencingEntity { TestEntity = entity }); 
         context.SaveChanges(); 
        } 
        transactionScope.Complete(); 
       } 
      }   
     } 

     private void ValidateEntities() 
     { 
      while (m_Count > 0 && !m_Failed) 
      { 
       if (FreeEntitiesExist()) 
       { 
        m_Failed = true; 
       } 
      }    
     } 

     [TestMethod] 
     public void TestIsSaveChangesAtomic() 
     { 
      var addTask = Task.Factory.StartNew(AddEntities); 
      var readTask = Task.Factory.StartNew(ValidateEntities); 

      addTask.Wait(); 
      readTask.Wait(); 

      Assert.IsFalse(FreeEntitiesExist(), "sanity failed"); 
      Assert.IsFalse(m_Failed, "test failed"); 
     } 

     private static bool FreeEntitiesExist() 
     { 
      using (var context = new TestContext()) 
      { 
       return (from entity in context.TestEntities 
         where !context.ReferencingEntities.Any(re => re.TestEntity.TestEntityId == entity.TestEntityId) 
         select entity) 
         .ToArray().Any(); 
      } 
     } 
    } 
} 
+0

Questo potrebbe essere un "lettura dirty", a seconda del database che si sta utilizzando e il livello di isolamento. SQL Server, ad esempio, ha un livello di isolamento 'READ UNCOMMITTED' (http://msdn.microsoft.com/en-us/library/ms173763(v=sql.100).aspx) che consente a un thread di leggere i dati inseriti da un altro thread in una transazione prima che sia stato eseguito il commit. I dati sono "sporchi" nel senso che potrebbero "scomparire" dal database quando il secondo thread decide di eseguire il rollback della transazione. Ma 'READ UNCOMMITTED' non è l'impostazione predefinita in SQL Server. – Slauma

+0

@Slauma Se sta utilizzando SQL Server con il pool di connessioni, è probabile che stia ottenendo una connessione che [eredita un livello di isolamento impostato precedentemente] (http://support.microsoft.com/kb/972915). @OhadMeir Potresti provare a racchiudere le tue operazioni in un 'TransactionScope' con un livello di isolamento impostato in modo esplicito su' IsolationLevel.ReadCommitted' e vedere se l'errore continua. –

+0

aggiunto IsolationLevel.ReadCommitted - il test non riesce ancora –

risposta

Problemi correlati