我们继承了一些使用Linq2Sql的代码，我们刚刚发现数据上下文的一个实例存储在一个定义为私有的类成员中。一旦创建了类，在Web应用程序中使用此类，将创建数据上下文的实例并将其分配给静态成员 - 从而生成现在将由该类的所有实例使用的数据上下文的实例（所以在所有用户中，本身就存在一个潜在的问题）而且数据上下文的实例现在将在Web应用程序的持续时间内存在（因为它保存在静态类成员中）。
忽略最初采取的错误设计决策，我的问题是读入数据上下文的数据会发生什么？我知道NHibernate中的会话保持对它读取/创建的任何对象的引用，因此它可以跟踪更改等，并且会话可以缓慢增长和增长，并且永远不会清除，除非您隐式告诉它。 Linq2Sql是否做了类似的事情，所以如果Web应用程序永远存在（没有回收），这个linq2Sql上下文会慢慢增长，直到机器内存不足，或者可能通过满足传入请求读取整个数据库？我的理解是，上下文通常不像缓存，它会删除自身“过期”的项目，或者当达到内存限制时，开始删除最少使用的项目。由于它的作用，我不认为数据上下文能够做到这一点吗？有没有人有这方面的经验，要么确认我的理解，要么提供一个参考，以显示长期存在的数据上下文可以做些什么来阻止这种情况发生。
答案 0 :(得分：3)
是的，如果DataContext属性设置为ObjectTrackingEnabled，true将跟踪已读取的对象。它默认启用。如果ObjectTrackingEnabled已经跟踪状态，则无法将DataContext的值更改为false。
当我们只是在进行读取而无意进行任何更改时，我们将ObjectTrackingEnabled设置为false。当SubmitChanges设置为false时，您无法致电ObjectTrackingEnabled。
我希望有所帮助。
答案 1 :(得分：3)
是的，DataContext将保留对与之关联的所有对象的引用。 可能是已被删除的对象将被从缓存中驱逐出来，但无论它将花费多少内存，它都会保留在缓存中。
根据数据集的体系结构和大小，工作进程在某些时候会耗尽内存并崩溃。唯一的补救措施是禁用对象跟踪（通过ObjectTrackingEnabled）或重构代码，以便每个请求使用一个DataContext，或者（并且不建议这样做）定期回收应用程序 - 宽DataContext。