Linq to SQL 奇怪的缓存？答案

【问题标题】：Linq to SQL Strange Caching?Linq to SQL 奇怪的缓存？
【发布时间】：2009-05-31 13:39:37
【问题描述】：

我在 Linq to SQL 中遇到了一个奇怪的错误/功能（如果我错了，请纠正我），这让我感到困惑并试图了解正在发生的事情。

因此，我按程序完成了整个过程，希望能找到解决方案，但目前无法解决。

这是正在发生的事情的重现：

记录对数据库表“ETickets”所做的更改。将“可用性”列从 9 更改为至 8（见下文） Change made to database http://www.composeandshoot.com/soverflow/changemadetodb.jpg
刷新页面，其中有一个 ASP 转发器数据绑定到 ETickets 表。这仍然显示“9”。
查看了有关数据绑定的 quickwatch 以查看从数据库返回的值（见下文）： quickwatch http://www.composeandshoot.com/soverflow/linqtosqlquickwatch.jpg
然后我查看了 SQL 服务器上运行的查询。启动 SQL Server Profiler 并得到以下结果（见下文）： SQL profiler http://www.composeandshoot.com/soverflow/linqquery.jpg
运行查询

exec sp_executesql N'SELECT [t0].[id], [t0].[eventid], [t0].[availability], [t0].[cost] FROM [dbo].[ETTickets] AS [t0] WHERE [t0].[id] = @p0',N'@p0 uniqueidentifier',@p0='2642C0EF-C0C5-4881-9AC8-53C023B444D2'
SQL Server 返回“8”作为可用性！然而数据绑定仍然显示“9”。我没有启用任何 SQL Cache Dependency。

请有人在这里指出正确的方向吗？谢谢。

【问题讨论】：

【解决方案1】：

数据上下文的生命周期是什么？它是 same 数据上下文，还是每次都是新的？（应该是后者）。

如果您重复使用数据上下文，则它必须始终将相同的对象还给您，只要它看起来是相同的身份。因此，如果它之前为您提供了 9 的版本，即使基础数据发生更改，它也会继续为您提供该引用。

目前，这仍然是往返；为避免往返，您需要使用：

var obj = ctx.SomeTable.Single(x=>x.Id == id);

即如果本地身份缓存中已经有Id == id 的对象，则根本不会执行数据库查询。

任何其他构造都会进行往返。有一个fix in 4.0 这样.Where(x=>x.Id == id).Single() 将避免往返，这应该具有查询语法，即

var obj = (from x in ctx.SomeTable
           where x.Id == id
           select x).Single();

【讨论】：

我正在创建一个部分类，然后我将公开 IQueryable 方法。这是使用相同的数据上下文，正如您所说的那样，这将返回相同的对象。所以我现在在页面本身及其工作上创建了一个新的数据上下文实例。只是出于好奇，我的第一种方法可行吗？ - 因为我非常希望将所有方法限制在一个部分类中，以便在我的整个应用程序中轻松更新。非常感谢。
如果你在在页面之间重用数据上下文，你将会在线程和锁定方面遇到巨大的问题；身份跟踪+变化跟踪意味着你会慢慢地堵塞一切。简而言之;数据上下文是短暂的和本地化的。

【解决方案2】：

您是否正在使用一个 DataContenxt 进行更新，而您后来查询的那个仍然存在？

如果是，这就是您应该期待的回应。

如果您在更新后创建了一个新的 DataContenxt，或者更新和读取是在同一个 DataContext 上完成的，您应该得到正确的响应。

【讨论】：