Linq-to-sql 上下文数据库连接处理答案

【问题标题】：Linq-to-sql context database connection handlingLinq-to-sql 上下文数据库连接处理
【发布时间】：2011-09-20 16:09:31
【问题描述】：

linq-to-sql 数据上下文如何保持数据库连接打开的规则是什么？

当我们对每个更新的实体的一个 SubmitChanges() 而不是整批实体的一个 SubmitChanges() 进行一些性能测试时，问题就出现了。结果：

在一次 SubmitChanges() 调用中插入 3000 个项目...持续时间：1318 毫秒

在一次 SubmitChanges() 调用中插入 3000 个项目，在 transactionscope...持续时间：1280ms

在单个 SubmitChanges() 调用中插入 3000 个项目... 持续时间： 4377毫秒

在单个 SubmitChanges() 调用中插入 3000 个项目事务...持续时间：2901ms

请注意，在为每个更改的实体执行单独的SubmitChanges() 时，将所有内容放在事务中提高性能，这对我们来说是非常出乎意料的。在 sql server profiler 中，我们可以看到事务中的单个 SubmitChanges() 调用不会为每个调用重置数据库连接，而不是没有事务的调用。

在什么情况下数据上下文保持连接打开？有没有关于 linq-to-sql 如何处理连接的详细文档？

【问题讨论】：

标签： c# .net linq-to-sql

【解决方案1】：

你没有展示整个图片；默认情况下，LINQ-to-SQL 将对SubmitChanges 的调用包装在事务中。如果您用另一个事务包装它，那么您将看不到连接重置；直到所有 SubmitChanges 调用完成，然后提交外部事务时，它才能完成。

【讨论】：

【解决方案2】：

除了打开/关闭连接的时间之外，还有许多因素可能会影响时间。

编辑：在意识到 linq2sql 如何分别管理缓存实体和脏实体后，我删除了有关跟踪实体的部分。

您可以通过使用 Reflector 或其他一些反汇编程序检查 SqlConnectionManager 类上的方法来了解如何在幕后管理连接。如果 SubmitChanges 将提交包装在自己的事务中，则 SubmitChanges 将在其 IProvider（通常是 SqlProvider，然后使用 SqlConnectionManager）上调用 ClearConnection，但如果 SubmitChanges 是更大事务的一部分，则不会。何时打开和关闭连接取决于是否有其他活动使用 SqlConnectionManager。

【讨论】：

DataContext 确实跟踪更改的对象，但在默认生成的代码中（在本例中由 dbml 设计器生成）它使用 INotifyPropertyChanging 和 INotifyPropertyChanged。实现这些后，无需遍历所有对象。无论如何，你是对的，被跟踪实体的数量越来越大。

【解决方案3】：

我最近也搞砸了。调用SubmitChanges 3000 次不是一个好主意，但是根据插入每条记录的重要性，您可能想要这样做，毕竟它只需要 1000 毫秒。

事务范围和多个SubmitChanges 是我希望看到的。由于您仍在一个事务中，我希望看到 SQL 服务器能更好地处理这个问题，这似乎是。一个SubmitChanges 和使用显式/隐式TransactionScope 似乎会产生相同的结果，这是意料之中的。那里不应该有任何/很大的性能差异。

我认为 连接是在需要时创建的，但您必须记住，这将在您的提供程序中汇集，因此除非您的连接字符串发生变化，否则您应该连接到同一个连接池，这将产生无论采用何种方法，性能都相同。由于 LINQ-SQL 在幕后使用SqlConnection，因此有关它的一些信息如下：

http://msdn.microsoft.com/en-us/library/8xx3tyca(VS.80).aspx

如果您在蛮力之后表现出色，请考虑使用显式 TransactionScope 进入存储过程以进行插入。如果这还不够快，请查看使用SqlBulkCopy。 3000 行的插入速度应该超过 1000 毫秒。

【讨论】：

【解决方案4】：

您是否尝试过自己打开和关闭连接： Force the Opening of the DataContext's Connection (LINQ)

我认为在这种情况下你不需要额外的交易。

【讨论】：