Зачем использовать Singleton для управления подключением БД?

Question

Я знаю, что об этом спрашивали раньше здесь и везде, но я не могу получить четкое объяснение, поэтому я собираюсь передать это снова. Так в чем же суть использования синглтона для управления соединением базы данных в вашем веб-приложении? Кому-то это нравится, кому-то это не нравится, я этого не понимаю. Из того, что я прочитал, «это для того, чтобы всегда иметь только одно активное соединение с вашей БД». Я имею в виду, почему это хорошо? 1 активное соединение с БД в управляемом данными веб-приложении, обрабатывающем несколько запросов в секунду, не так ли? По какой-то причине никто не может правильно объяснить это. Я был во всем Интернете. Я знаю, что я толстый.

Answer 1

Предполагается, что здесь используется Java, но также относится и к большинству других технологий.

Я не уверен, что вы спутали использование простого синглтона с сервисным локатором . Оба они являются шаблонами дизайна. Шаблон локатора службы используется приложениями, чтобы гарантировать, что существует один класс, которому поручено получать и предоставлять доступ к базам данных, файлам, очередям JMS и т. Д.

Большинство сервисных локаторов реализованы как одиночные, так как нет необходимости, чтобы несколько сервисных локаторов выполняли одну и ту же работу. Кроме того, полезно кэшировать информацию, полученную при первом поиске, которая впоследствии может быть использована другими клиентами локатора службы.

Кстати, аргумент о

"это чтобы убедиться, что всегда есть только одно активное соединение с вашей БД "

является ложным и вводящим в заблуждение. Вполне возможно, что соединение может быть закрыто / восстановлено, если оставлено неактивным в течение довольно длительного периода времени. Так что кеширование соединения с базой данных не одобряется. Есть одно отклонение от этого аргумента; «повторное использование» соединения, полученного из пула соединений, рекомендуется при условии, что вы делаете это с тем же контекстом, то есть в рамках того же HTTP-запроса или запроса пользователя (в зависимости от того, что применимо). Это сделано, очевидно, с точки зрения производительности, поскольку установление новых соединений может оказаться дорогостоящей операцией.

Answer 2

Высокопроизводительные (или даже средние) веб-приложения используют базу данных пул соединений , поэтому одно соединение с БД может совместно использоваться многими веб-запросами. Синглтон обычно является объектом, который управляет этим пулом. Я думаю, что мотивация для использования синглтона состоит в том, чтобы защищать от дурака программистов, которые в противном случае могли бы создавать ненужные экземпляры многих из этих объектов.

Answer 3

"это гарантирует, что всегда есть только одно активное соединение с вашей БД." Я думаю, что было бы лучше заявить, чтобы гарантировать, что каждый КЛИЕНТ имеет только одно активное соединение с вашей БД. Причина, по которой это невероятно важно, заключается в том, что вы хотите предотвратить взаимные блокировки. Если у меня есть ДВА открытых соединения с базой данных (в качестве клиента), я могу обновлять одно соединение, тогда я могу попытаться обновить ту же строку в другом соединении. Это будет тупик, который база данных не сможет обнаружить. Итак, идея синглтона заключается в том, чтобы убедиться, что существует ОДИН объект, который отвечает за раздачу соединений с базой данных каждому клиенту. В принципе. Вы не должны иметь синглтон для этого, но большинство людей скажут вам, что просто имеет смысл, что система имеет только один.

Answer 4

вы больше ищете одно соединение на запрос, а не одно соединение для всего приложения. вы по-прежнему можете контролировать доступ к нему через одноэлементный файл (сохраняя соединение в коллекции HttpContext.Items).

Answer 5

Я думаю, что вы, возможно, захотите быть более конкретным в отношении «использования синглтона для управления соединением БД в вашем веб-приложении». В идеале, объект java.sql.Connection не будет поточно-ориентированным, но ваш javax.sql.DataSource может захотеть объединить соединения, поэтому вы должны обратиться к одному его экземпляру для совместного использования пула.

Answer 6

«только одно активное соединение» - очень узкое утверждение для иллюстрации. С таким же успехом это может быть одноэлементное управление пулом соединений. Смысл единого подхода к соединениям с базой данных заключается в том, что вы не хотите, чтобы каждый потребитель делал свое собственное соединение или набор соединений.

Answer 7

Я не думаю, что это простой ответ. Например, в ASP.NET платформа реализует пул соединений по умолчанию, поэтому она автоматически настраивает «пул» соединений и повторно использует их, чтобы вы не создавали и не уничтожали дорогостоящие объекты.

Однако предположим, что вы писали приложение для сбора данных, которое отслеживало 200 отдельных входных источников. Каждый раз, когда один из этих входов изменяется, вы запускаете поток, который записывает событие в базу данных. Я бы сказал, что это может быть плохой дизайн, если есть вероятность, что даже часть из них может сработать одновременно. Внезапно иметь 20 или 40 активных подключений к базе данных неэффективно. Возможно, было бы лучше поставить обновления в очередь, и пока в очереди остаются обновления, одноэлементное соединение отбирает их из очереди и выполняет их на сервере. Это более эффективно, потому что вам нужно согласовать соединение и аутентификацию только один раз. Как только какое-то время не будет активности, вы можете закрыть соединение. Такое поведение было бы трудно реализовать без центрального менеджера ресурсов, например, синглтона.

Answer 8

Возможно, вы захотите использовать синглтон из-за ограничений сервера базы данных, например, сервер может ограничить количество соединений.

Моя главная сознательная причина в том, что вы знаете, какие соединения могут управляться / закрываться и т. Д., Просто делает вещи немного более организованными, когда у вас нет ненужных, избыточных соединений.

Answer 9

Это гарантирует, что каждый клиент, использующий ваш сайт, получает только одно соединение с БД. Вы действительно не хотите, чтобы новое соединение устанавливалось каждый раз, когда пользователь выполняет действие, которое создаст запрос БД. Не только по соображениям производительности с включенным подтверждением связи, но и для уменьшения нагрузки на сервер БД.

Соединения с БД являются ценным товаром, и этот метод помогает минимизировать количество, используемое в любой момент времени.

Answer 10

Ты прав - обычно это не то, что ты хочешь.

Однако во многих случаях вам нужно ограничить себя одним соединением. Сериализовав ваш доступ к базе данных через единый пакет, вы можете решить другие проблемы или ограничения, такие как загрузка, пропускная способность и т. Д.

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