LINQ-如果我有很多更改，我应该以某种方式定期提交changes()吗
本文关键字：方式定 提交 changes 我应该 如果 LINQ- | 更新日期: 2023-09-27 18:06:18
我有一批"机器人"，它们在阅读RSS线程时运行，并将结果存储在数据库中，我将其并行化，以便一次获取许多提要：
Parallel.ForEach(context.Feeds, feed => ProcessRssFeed(feed, context));
context.SubmitChanges();
"ProcessRssFeed"函数可以在找到记录时将其插入上下文中，每个提要可以是零到数百个项目。有很多提要，所以我不想为每个提要创建一个LINQ DataContext。
不过，我担心我可能会在客户端上积累成千上万的记录。我想我的记忆力可能会耗尽。
如果可能的话，这里没有并发问题，我想告诉DataContext"如果你愿意的话，继续定期提交记录"。有什么切实可行的方法可以做到这一点吗？
我建议为每个创建一个新的DataContext。与实际的数据库连接相比，DataContexts的重量相当轻。DataContext在连接到数据库时使用连接池，使用单独的DataContext不会带来太多开销。
在DataContext中只保留需要原子提交的东西，提交它并为下一项创建一个新的DataContext。
没有用于定期提交的内置方法，但您可以查看DataContext.GetChangeSet()中的项目数，并在该计数超过给定阈值时提交。但是，只有当评测显示创建新的DataContexts确实是系统中的一个瓶颈时，才应该这样做。
如果有很多对象都有相当多的数据，那么就有可能开始增加内存使用量。DataContext将所有跟踪的更改存储在内存中，直到您调用SubmitChanges。我建议您测量一下程序的内存使用情况，看看这是否会成为您的问题。如果内存是一个问题，那么是的，您应该调用SubmitChanges，这样DataContext就可以从中清除一些信息。
不过，在单次调用中调用SubmitChanges有优点也有缺点。假设您确实有很多数据，并且您正在使用一个SubmitChanges调用。这将阻塞它所在的任何线程，直到它完成——在某些情况下，这可能需要非常长的时间。如果你想做一些事情，比如让线程恢复、报告进度或其他辅助操作，这是不好的。在这些情况下，您应该定期调用SubmitChanges，这样您就可以让线程继续处理其他逻辑(如果有(
如果你真的不在乎它需要多长时间，它不会影响其他任何事情，那么一个SubmitChanges调用就可以了。
但是，在任何一种情况下，SubmitChanges仍然将每个更改拆分为一个单独的命令，并单独执行每个命令。因此，它从不执行批量或批处理命令，它总是一个接一个地执行，无论您是定期调用SubmitChanges还是单个调用。
MSDN页面将帮助您更好地理解SubmitChanges。还有其他有用的资源分散在各处。