Первый подход, при котором все создается заново, примерно на 5 процентов медленнее второго.
В абсолютном исчислении это замедление составляет всего 0.08 миллисекунды на каждую итерацию, т.е. очень мало. Если учесть, что само обращение к базе выполняется на несколько порядков медленнее создания любого объекта, то выигрыш получается и вовсе умозрительный.
Какие выводы? Во-первых, логика восторжествовала – не создавать объекты оказалось быстрее, чем создавать. Во-вторых, это совершенно не важно. Разница в скорости между пересозданием объектов и использованием готовых настолько мала, что разработчик может смело выбирать тот или иной подход, руководствуясь только своим личным пониманием прекрасного.
Говоря же о практической экономии, можно сделать такую оценку: если у нас есть некая динамическая web-страница, которая делает одно обращение к базе, а к ней самой обращаются 10 раз в секунду, то сохранение объектов поможет нам выиграть целую секунду за полчаса.
Естественно, между этими двумя полярными вариантами есть большое число промежуточных состояний. Например, можно каждый раз создавать объект подключения, но хранить готовые команды. Этот подход, вероятно, весьма органично сочетается с визуальным дизайнером компонентов из Visual Studio. Набросав на компонент команды, мы получаем код для их инициализации, который выполняется при создании экземпляра компонента. Очевидно, что извлекать этот код из метода InitializeComponent неразумно, лучше просто назначить нужной команде тот объект подключения, который мы собираемся открывать в данный момент.
Повторное использование подключений
В то время как с повторным использованием командных объектов (SqlCommand, OleDbCommand и т.п.) все, в общем, понятно, вопрос повторного использования объекта подключения остается открытым. Нужно ли это кому-нибудь, а если нужно, то зачем?
Под «повторным» мы здесь понимаем такое использование, когда один и тот же объект подключения используется снова и снова во всех частях приложения, где нужен доступ к соответствующей базе данных. При этом мы сознаем, что все стандартные для ASP.NET объекты подключения не являются безопасными для многопоточного использования (non thread safe), поэтому для начала будем считать, что наше приложение имеет только один поток.
Какие проблемы могут возникнуть при подобном использовании объекта подключения? Во-первых, каждый раз, открывая подключение к базе данных, можно обнаружить, что оно уже было открыто раньше. Попытка открытия уже открытого подключения вызывает ошибку. Во-вторых, открытый объект DataReader блокирует свое подключение, так что до его закрытия выполнить еще какую-либо команду невозможно. Это может создать проблему в методе, вызванном во время чтения данных из базы.
Первую проблему обойти несложно. Достаточно проверять состояние подключения перед открытием, и пропускать этот шаг, если оно уже открыто. Здесь важно заметить, что метод, открывший подключение, обязательно должен его закрыть, так что, если проверка показала, что подключение нужно открывать, это значит и то, что его нужно закрыть после использования.
Обойти вторую проблему в том месте, где она дала о себе знать, невозможно. Действительно, данные уже читаются, подключение уже заблокировано, и сделать мы с этим ничего не можем. Единственное решение здесь – так проектировать блоки чтения, чтобы они даже потенциально не могли никого блокировать. Например, можно сначала прочитать все данные в массив, а уже потом проводить их дальнейшую обработку.
Основные проблемы ясны и достаточно серьезны. Какие преимущества могут быть у данного подхода? Перевешивают ли они недостатки?
Во-первых, мы можем существенно ускорить работу в тех приложениях, где свежеоткрытое подключение нужно специально готовить. Например, приложение может использовать application roles. Для входа в роль MS SQL Server требует выполнения хранимой процедуры sp_setapprole:
| EXEC sp_setapprole 'SalesApprole', 'AsDeFXX' |
Очевидно, что если обработка запроса состоит, к примеру, из пяти обращений к базе, то гораздо быстрее будет открыть подключение и выполнить эту команду один раз, нежели все пять. Сама операция открытия подключения требует очень мало времени – на это есть connection pooling. Лишнее же обращение к базе – это серьезный удар по быстродействию.
Естественно, я говорю не о простейшем случае, когда все пять обращений к базе находятся в одном методе. В конце концов, мы живем во времена победившего объектно-ориентированного подхода, так что «макаронный» код почти почил в бозе. Все эти обращения совершаются разными компонентами, обслуживающими запрос. Как быть в этом случае? Предлагается открыть подключение и выполнить эту команду в начале обработки запроса, а затем передать объект подключения в дальнейшее использование.
Представляется, что это преимущество выглядит достаточно серьезным (конечно, для определенного класса приложений). Кстати, здесь стоит обратить внимание еще на одну особенность: войдя в роль и рассчитывая на автоматический выход из нее по закрытию подключения, можно получить неприятный сюрприз в том случае, если подключение на самом деле закрыто не будет. Последующие обращения к БД, возможно, будут выполняться с несоответствующими правами. С другой стороны, это может случиться только в приложении с весьма специфической архитектурой.
Во-вторых, можно представить себе приложение, открывающее чересчур много подключений. Большущая вложенность вызовов. Может быть, даже рекурсия. Все методы открывают подключения и, не закрывая, вызывают другие методы. В таком (совершенно гипотетическом) приложении можно столкнуться с тем, что свободные подключения закончатся, и в какой-то момент времени мы не сможем открыть подключение к базе. Использование одного объекта подключения могло бы нас здесь спасти.
Впрочем, подобная проблема выглядит совершенно надуманной. Если она и имеет где-то место, то это, скорее, ошибка в проектировании приложения, и решать ее нужно другими способами.
Режимы функционирования менеджера
Вернемся к менеджеру подключений. Очевидно, что он мог бы функционировать в двух режимах: либо каждый раз создавать новый объект подключения, либо возвращать уже готовый экземпляр, соответствующий заданному логическому имени.
На практике менеджер, осуществляющий кэширование объектов подключения, должен успешно проходить вот такой тест:
| DbManager.Mode = DbManagerMode.CacheConnections;DbManager dbmgr =DbManager.Get();IDbConnection c1 = dbmgr["beta"];IDbConnection c2 = dbmgr["beta"];Assert.IsTrue( c1 == c2 ); // Менеджер возвращает один и тот же экземпляр |
А «простой» менеджер, т.е. не осуществляющий кэширование, такой:
| DbManager.Mode = DbManagerMode.DoNotCacheConnections;DbManager dbmgr =DbManager.Get();IDbConnection c1 = dbmgr["beta"];IDbConnection c2 = dbmgr["beta"];Assert.IsTrue( c1 != c2 ); // Менеджер возвращает разные экземпляры |
Подобная функциональность позволила бы разработчику легко выбирать между двумя описанными выше вариантами работы с подключениями, и даже без больших сложностей перейти с одного подхода на другой в уже частично написанном приложении.
Ранее мы рассматривали приложение, в котором есть только один поток (thread). Какие сложности могут встретиться, если потоков будет несколько?
По сути, сложность здесь только одна – один объект подключения можно одновременно использовать только в одном потоке. Если для каждого обращения создается новый объект подключения, то нас эта проблема совершенно не касается. Соответственно, менеджер подключений, работающий в этом режиме, очень прост в реализации. Метод, возвращающий объект подключения по имени, может выглядеть так:
| public override IDbConnection this[String name] { get { ConnectionInfo info = (ConnectionInfo)_config.Connections[name]; if( info != null ) { return CreateConnection( info );} return null; }} |
Несколько более сложно выглядят действия при кэшировании объектов подключения. С одной стороны, нужно организовать некий словарь готовых объектов, из которого выдаются объекты по запросу. С другой стороны, мы должны сделать так, чтобы каждый поток работал со своим экземпляром данного подключения. Пытаться реализовать такую функциональность в одном объекте, обслуживающем сразу все потоки, может быть слишком сложно. Поэтому предлагается сделать так, чтобы каждый экземпляр менеджера обслуживал только один поток. Очевидно, что в этом случае создается некоторое неопределенное количество экземпляров, не большее, чем общее количество потоков в приложении. Неопределенность обусловлена тем, что для потоков, в которых менеджер не требуется, создавать экземпляр не нужно.
Таким образом, нужно, во-первых, написать такой метод Get, который бы возвращал экземпляр, приписанный к вызывающему потоку, и, во-вторых, сделать словарь готовых объектов. Приблизительно так может выглядеть этот фрагмент кода:
| [ThreadStatic] private static DbManager _instance;private ListDictionary _connections = new ListDictionary();internal static new DbManager Get() { // Если экземпляр уже есть, вернуть егоif( _instance != null ) return _instance; // Создатьновыйэкземпляр _instance = new CachingDbManager(); _instance.Init(); return _instance;}public override IDbConnection this[String name] { get { // Пытаемся взять готовый объект из словаряIDbConnection result = (IDbConnection)_connections[name];if( result == null ) { // Ищем описание подключения в конфигурацииConnectionInfo info = (ConnectionInfo)_config.Connections[name]; if( info != null ) result = CreateConnection( info );} return result; }} |
Как известно, приложения ASP.NET весьма активно используют многопоточность. В то же время делают они это настолько неявно, что этот факт легко оставить без внимания и получить неожиданные ошибки.
Вспомним, в общих чертах, структуру обычного приложения ASP.NET. В домене приложения (AppDomain) есть несколько экземпляров класса HttpApplication. Каждый из этих экземпляров обладает набором сопутствующих ему модулей (HttpModule). Набор модулей у каждого приложения одинаков, да и сами приложения, по идее, не должны ничем отличаться. Далее, домен приложения имеет набор рабочих потоков (working threads), готовых обслуживать пользовательские запросы. Со всей очевидностью, потоков существует по крайне мере столько же, сколько объектов Http-приложения.