Почему Singleton использования для управления подключением дб?

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

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

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

Между прочим, аргумент о

"это должно гарантировать, что всегда существует только одно активное соединение к Вашему DB"

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

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

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

Вы правы - обычно это не то, что Вы хотите.

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

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

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

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

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

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

"только одно активное соединение" является очень узким оператором для иллюстрации. Это мог точно также быть одиночный элемент, управляющий пулом соединения. Точка одиночного элемента для соединений с базой данных - то, что Вы не хотите каждого потребителя, устанавливающего свою собственную связь или набор соединений.

Я думаю, что Вы могли бы хотеть быть более конкретными относительно, "с помощью одиночного элемента для управления соединением дб в веб-приложении". Идеально, java.sql. Объект соединения не будет ориентирован на многопотоковое исполнение, но Ваш javax.sql. DataSource может хотеть объединить соединения, таким образом, необходимо перейти к единственному экземпляру его для совместного использования объединения.

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

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

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