2

我有一批“机器人”围绕读取 RSS 线程运行并将结果存储在数据库中，并且我将其并行化以便可以一次获取许多提要：

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

'ProcessRssFeed' 函数可以在找到记录时将它们插入到上下文中，并且每个提要可以是从零到数百个项目的任何地方。有很多提要，所以我不想为每个提要创建一个 LINQ DataContext。

不过，我担心我可能会在客户端上积累成千上万条记录。我想我可能会耗尽内存。

因为如果可能的话，这里没有并发问题，我想告诉 DataContext “如果你愿意，请继续并定期提交记录”。有没有一些实用的方法来实现这一点？

4

2 回答 2

3

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

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

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

于 2011-08-23T04:58:24.587 回答
1

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

不过，在单个调用中调用 SubmitChanges 有优点和缺点。假设您确实有很多数据，并且您正在使用单个 SubmitChanges 调用。这将阻塞它所在的任何线程，直到它完成 - 在某些情况下，这可能是非常非常长的时间。如果您想做一些事情，比如让线程恢复、报告进度或其他副操作，这很糟糕。在这些情况下，您应该定期调用 SubmitChanges，以便让线程恢复处理其他逻辑（如果有或需要）。

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

但是，无论哪种情况，SubmitChanges 仍然将每个更改拆分为一个单独的命令，并单独执行每个命令。因此，它永远不会执行批量或批处理命令，它始终是一个接一个的，无论您是定期调用 SubmitChanges 还是一次调用。

这个MSDN 页面将帮助您更好地理解 SubmitChanges。周围还有其他有用的资源。

于 2011-08-23T07:36:30.937 回答