EF 5.0 DbContext并发性的多个实例

Question

我试图模拟一个场景，有多个单独的应用程序访问我的数据库。我这样做的方式是创建10个不同的线程，这使得一些并发事务等。每个线程都有一个我的DbContext实例。

问题是，DbContexts不知道其他实例中的更新。所以我的问题是，我如何确保我的DbContexts不包含不一致的数据？

Answer 1

如果使用除Serializable以外的任何隔离级别，则可能会导致某些级别的数据不一致。可串行化在性能方面相当昂贵，仅用于非常特殊的情况。

SERIALIZABLE 指定如下： 声明不能读取已修改但其他事务尚未提交的数据。 在当前事务完成之前，没有其他事务可以修改当前事务读取的数据。 其他事务不能插入具有键值的新行，这些键值落在当前事务中任何语句读取的键范围内，直到当前事务完成。 范围锁放置在与事务中执行的每个语句的搜索条件相匹配的键值范围内。这会阻止其他事务更新或插入任何符合当前事务执行的任何语句的行。这意味着如果事务中的任何语句再次执行，它们将读取相同的一组行。范围锁定一直持续到事务完成。这是隔离级别最严格的原因，因为它锁定了整个键的范围并持有锁直到事务完成。由于并发性较低，因此仅在必要时才使用此选项。此选项与在事务中的所有SELECT语句的所有表上设置HOLDLOCK的效果相同。

快照隔离还可以防止脏，不可重复和幻像读取，但不会阻止线程1和线程2在重叠时间段内观察不同的数据。

快照 指定任何声明在一个事务中读取的数据将是在事务开始时就存在的数据的事务上一致的版本。该交易只能识别交易开始前已提交的数据修改。在当前事务开始后由其他事务进行的数据修改对当前事务中执行的语句不可见。其效果就好像事务中的语句获取了事务开始时所存在的已提交数据的快照。

这是一个相当广泛的话题。一个好的起点是

http://technet.microsoft.com/en-us/library/ms189122(v=sql.105).aspx

交易指定定义哪一个事务必须从其它事务做出资源或数据修改被分离的程度的隔离级别。描述隔离级别的术语是允许并发副作用，如脏读或幻读。

Answer 2

问题是他们缓存他们调用的数据库表。无论何时更新已经缓存的数据库表，您都必须创建一个新的dbContext。

你也可以尝试搞定缓存设置，以使它们更快地超时，所以更新的结果会更快地反映在其他dbContexts中（例如测试启用和禁用延迟加载）。我诚实地从未尝试过与他们玩太多;我一直只是做了一个新的dbContext，并为我工作。