我试图模拟一个多个单独的应用程序访问我的数据库的场景。我这样做的方式是创建10个不同的线程，这会产生一些并发事务等。每个线程都有一个我的DbContext实例。
问题是，DbContexts不知道其他实例中的更新。所以我的问题是，如何确保我的DbContexts不包含不一致的数据？
答案 0 :(得分：1)
如果使用除Serializable之外的任何隔离级别，则会冒一定程度的不一致数据。 Serializable在性能方面相当昂贵，仅用于非常特殊的情况。
SERIALIZABLE 指定以下内容： 语句无法读取已修改但尚未由其他事务提交的数据。 在当前事务完成之前，没有其他事务可以修改当前事务已读取的数据。 其他事务无法插入新行，其键值将落在当前事务中任何语句读取的键范围内，直到当前事务完成为止。 范围锁定位于与事务中执行的每个语句的搜索条件匹配的键值范围内。这会阻止其他事务更新或插入任何符合当前事务执行的任何语句的行。这意味着如果事务中的任何语句第二次执行，它们将读取同一组行。范围锁保持到事务完成。这是隔离级别中最具限制性的，因为它会锁定整个键范围并保持锁定直到事务完成。由于并发性较低，因此仅在必要时使用此选项。此选项与在事务中所有SELECT语句中的所有表上设置HOLDLOCK具有相同的效果。
快照隔离还可以防止脏，不可重复和幻像读取，但不会阻止线程1和线程2在重叠时间段内观察不同的数据。
快照 指定事务中任何语句读取的数据将是事务开始时存在的事务一致的数据版本。事务只能识别在事务开始之前提交的数据修改。在当前事务开始之后由其他事务进行的数据修改对于在当前事务中执行的语句是不可见的。效果就好像事务中的语句获得了在事务开始时存在的已提交数据的快照。
这是一个相当广泛的话题。一个很好的起点是
http://technet.microsoft.com/en-us/library/ms189122(v=sql.105).aspx
事务指定隔离级别，该级别定义一个事务必须与其他事务所做的资源或数据修改隔离的程度。隔离级别是根据允许的并发副作用（例如脏读或幻像读取）来描述的。
答案 1 :(得分：1)
问题是他们缓存了他们调用的数据库表。只要对已缓存的数据库表进行更新，就必须创建新的dbContext。
您还可以尝试使用缓存设置来使它们更快地超时，因此更新的结果将更快地反映在其他dbContexts中（例如，测试启用和禁用延迟加载）。我老实说从来没有试过过多玩过它们;我总是创建一个新的dbContext，这对我有用。