Обработка подключения к контекстной базе данных Linq-to-sql

Question

Каковы правила того, как datacontext из linq-to-sql поддерживает соединение с базой данных открытым?

Возник вопрос, когда мы сделали несколько тестов производительности для одного SubmitChanges() на обновленный объект вместоодин SubmitChanges() для всей партии объектов.Результаты:

Вставка 3000 элементов в одном вызове SubmitChanges () ... Продолжительность: 1318мс

Вставка 3000 элементов в одном вызове SubmitChanges () в пределах транзакции ... Продолжительность: 1280мс

Вставка 3000 элементов в отдельные вызовы SubmitChanges () ... Продолжительность: 4377мс

Вставка 3000 элементов в отдельные вызовы SubmitChanges () внутри транзакции ... Продолжительность: 2901мс

Обратите внимание, что при выполнении отдельных SubmitChanges() для каждой измененной сущности размещение всего в транзакции повышает производительность , что для нас было совершенно неожиданным.В профилировщике сервера sql мы видим, что отдельные вызовы SubmitChanges() внутри транзакции не сбрасывают соединение с БД для каждого вызова, в отличие от соединения без транзакции.

В каких случаях происходит контекст данныхдержать соединение открытым?Есть ли подробная документация о том, как linq-to-sql обрабатывает соединения?

Answer 1

Может быть ряд факторов, которые могут влиять на время, кроме того, когда соединения открываются / закрываются.

edit: я удалил немного о отслеживаемых сущностях после того, как понял, как linq2sql управляет кэшированными сущностями игрязные сущности отдельно.

Вы можете получить хорошее представление о том, как управлять соединениями под прикрытием, используя Reflector или какой-либо другой дизассемблер, чтобы проверить методы класса SqlConnectionManager.SubmitChanges будет вызывать ClearConnection на своем IProvider (обычно SqlProvider, который затем использует SqlConnectionManager) после отправки, если он заключает в себе отправку в своей собственной транзакции, но не в том случае, если SubmitChanges является частью более крупной транзакции.Когда соединение открывается и закрывается, зависит от того, есть ли другая активность, использующая SqlConnectionManager.

Answer 2

Вы не показываете всю картинку; По умолчанию LINQ-to-SQL будет заключать вызов в SubmitChanges в транзакции. Если вы заключите его в другую транзакцию, вы не увидите сброса соединения; не может, пока все из SubmitChanges вызовов не будут завершены, а затем, когда будет совершена внешняя транзакция.

Answer 3

Вы пытались открыть и закрыть соединение самостоятельно: Принудительное открытие соединения DataContext (LINQ)

Я думаю, что в этом случае вам не нужна дополнительная транзакция.

Answer 4

В последнее время я тоже с этим сталкивался. Вызов SubmitChanges 3000 раз не будет хорошей идеей, но тогда, в зависимости от того, насколько важно, чтобы каждая запись была вставлена, вы можете сделать это, в конце концов, это займет всего 1000 мс.

Объем транзакции и кратный SubmitChanges - это то, что я ожидал увидеть. Поскольку вы все еще в пределах одной транзакции, я ожидал бы, что SQL-сервер справится с этим лучше, что кажется. Один SubmitChanges и использование явного / неявного TransactionScope, похоже, дают тот же результат, что и следовало ожидать. Там не должно быть никакой разницы в производительности.

Я думаю, что соединения создаются, когда это необходимо, но вы должны помнить, что это будет объединено с вашим провайдером, поэтому, если ваша строка соединения не меняется, вы должны подключиться к тому же пулу соединений, который даст тот же производительность независимо от подхода. Поскольку LINQ-SQL использует SqlConnection за кулисами, некоторая информация об этом находится по следующему адресу:

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

Если ваша производительность после грубой силы, посмотрите на переход в Stored Proceedure для вставки с явным TransactionScope. Если это не достаточно быстро, посмотрите на использование SqlBulkCopy. 3000 строк должны вставляться быстрее, чем 1000 мс.