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

Question

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

问题来了，当我们对一个做对性能有一些测试SubmitChanges()每更新的实体，而不是一个SubmitChanges()为单位的整批。 结果：

在一个SubmitChanges（）调用中插入3000个项目...时长：1318ms

在transactionscope内的一个SubmitChanges（）调用中插入3000个项目...时长：1280ms

在单个SubmitChanges（）调用中插入3000个项目...时长：4377ms

在事务中的各个SubmitChanges（）调用中插入3000个项目...时长：2901ms

请注意，当对每个更改的实体进行单独的SubmitChanges() ，将所有内容放入事务中都可以提高性能，这对我们来说是非常意外的。 在sql server profiler中，我们可以看到事务中的各个SubmitChanges()调用不会重置每个调用的数据库连接，这与没有事务的调用相反。

在什么情况下，数据上下文会使连接保持打开状态？ 是否有任何有关linq-to-sql如何处理连接的详细文档？

Answer 1

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

Answer 2

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

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

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

Answer 3

最近我也弄混了。 调用SubmitChanges 3000次不是一个好主意，但是根据插入每个记录的关键程度，您可能要这样做，毕竟只需要1000毫秒。

我希望看到交易范围和多个SubmitChanges 。 由于您仍在一次事务中，因此我希望SQL Server能够更好地处理这一点，这看起来似乎不错。 一个SubmitChanges并使用显式/隐式TransactionScope似乎会产生相同的结果，这是可以预期的。 那里应该不存在任何/大部分性能差异。

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

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

如果您的表现强力，可以考虑使用显式TransactionScope进入存储过程进行插入。 如果那还不够快，请考虑使用SqlBulkCopy 。 3000行应比1000ms快。

Answer 4

您是否尝试过自己打开和关闭连接： 强制打开DataContext的连接（LINQ）

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