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

本文关键字：数据库连接 上下文 Linq-to-sql 处理 | 更新日期: 2023-09-27 18:09:03

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

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

在一个SubmitChanges()调用中插入3000个条目…持续时间:1318 ms

在一个SubmitChanges()调用中插入3000个条目transactionscope……持续时间:1280 ms

在单个SubmitChanges()调用中插入3000个条目…持续时间:4377 ms

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

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

在什么情况下数据上下文保持连接打开?有关于如何处理连接的详细文档吗?

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

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

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

edit:在意识到linq2sql如何分别管理缓存实体和脏实体之后，我已经删除了关于跟踪实体的部分。

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

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

事务范围和多个SubmitChanges是我所期望看到的。因为你仍然在一个事务，我希望看到SQL服务器处理这个更好，它似乎。一个SubmitChanges和使用显式/隐式TransactionScope似乎产生相同的结果，这是意料之中的。应该不会有任何/太多的性能差异。

我认为连接是在需要的时候创建的，但你必须记住，这将在你的提供者中池化，所以除非你的连接字符串改变，否则你应该挂钩到相同的连接池，这将产生相同的性能，无论采用哪种方法。由于LINQ-SQL在幕后使用SqlConnection，有关它的一些信息如下:

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

如果您追求蛮力性能，请考虑使用显式TransactionScope进入插入的存储过程。如果这还不够快，可以考虑使用SqlBulkCopy。

你试过自己打开和关闭连接吗?强制打开DataContext's连接(LINQ)

我认为这样的话，您就不需要额外的交易了。

相关文章：