LINQ - 如果我有很多变化，我应该定期提交更改（）吗？

Question

我有一批'机器人'，它们围绕着阅读RSS线程并将结果存储在数据库中，我将其并行化，以便可以同时获取许多源：

Parallel.ForEach(context.Feeds, feed => ProcessRssFeed(feed, context));
context.SubmitChanges();

'ProcessRssFeed'功能可以在找到记录时将记录插入到上下文中，每个Feed可以是从零到数百个项目的任何位置。有很多feed，所以我不想为每个创建一个LINQ DataContext。

但是，我很担心，我可以在客户端累积成千上万的记录。我想我可能会耗尽内存。

由于这里没有并发问题，如果可能的话，我想告诉DataContext“如果你愿意，可以定期提交记录”。有没有一些实用的方法来实现这个目标？

Answer 1

我建议为每个人创建一个新的DataContext。与实际数据库连接相比，DataContexts的重量非常轻。 DataContext在连接到数据库时使用连接池，使用单独的DataContexts不会产生太多开销。

只保留需要在DataContext中以原子方式提交的内容，提交并为下一个项目创建新的DataContext。

没有用于定期提交的内置方法，但您可以查看DataContext.GetChangeSet()中的项目数，并在该计数超过给定阈值时提交。但是，如果分析显示创建新的DataContexts确实是系统中的瓶颈，那么你应该这样做。

Answer 2

如果您有许多具有相当多数据的对象，则可以开始增加内存使用量。 DataContext将所有跟踪的更改存储在内存中，直到您调用SubmitChanges。我建议您测量程序的内存使用情况，看看这是否会成为您的问题。如果内存是一个问题，那么你应该调用SubmitChanges，以便DataContext可以从那里刷新一些信息。

虽然在单个呼叫中调用SubmitChanges有优点和缺点。假设您确实拥有大量数据并且正在使用单个SubmitChanges调用。这将阻止它完成之前的任何线程 - 在某些情况下，这可能是非常非常长的时间。如果您想要执行诸如让线程恢复，报告进度或其他辅助操作之类的操作，那么这很糟糕。在这些情况下，您应该定期调用SubmitChanges，这样您就可以让线程恢复处理其他逻辑，如果它有任何或需要的话。

如果你真的不在乎它需要多长时间，它不会影响任何其他因素，那么单个SubmitChanges调用就可以了。

在任何一种情况下，SubmitChanges仍会将每个更改拆分为单个命令，并单独执行每个命令。因此，它永远不会执行批量命令或批处理命令，它总是一个接一个，无论您是定期调用SubmitChanges还是单个调用。

此MSDN page将帮助您更好地理解SubmitChanges。还有其他有用的资源。