Dlaczego warto używać Singleton do zarządzania połączeniem db?

Question

Wiem, że zostało to zadane przedtem tutaj i wszędzie, ale nie mogę uzyskać jasnego wyjaśnienia, więc zamierzam je jeszcze raz rozłożyć. Więc jakie jest całe zamieszanie związane z używaniem singletona do kontrolowania połączenia db w twojej aplikacji internetowej? Niektórzy lubią to nienawidzą, nie rozumiem tego. Z tego, co przeczytałem, "wynika, że ​​zawsze jest tylko jedno aktywne połączenie z twoją bazą danych". Mam na myśli, dlaczego to jest dobra rzecz? 1 aktywne połączenie DB w aplikacji sieciowej opartej na danych przetwarzającej wiele żądań na czary na sekundę, prawda? Z jakiegokolwiek powodu nikt nie może tego odpowiednio wyjaśnić. Byłem w Internecie. Wiem, że jestem gruby.

Answer 1

Masz rację - zazwyczaj nie jest to, czego chcesz.

Jednak istnieje wiele przypadków, w których trzeba dławić się do jednego połączenia. Serializując dostęp do bazy danych za pomocą pojedynczej wersji, można rozwiązać inne problemy lub ograniczenia, takie jak obciążenie, przepustowość itp.

Zrobiłem coś podobnego w przeszłości dla aplikacji do przetwarzania zbiorczego. Zamiast tego użyłem semafora do zsynchronizowania dostępu do bazy danych, więc mogłem zezwolić na n równoczesnych operacji db.

Answer 2

Gwarantuje to, że każdy klient korzystający z witryny otrzymuje tylko jedno połączenie z bazą danych. Naprawdę nie chcesz, aby nowe połączenie było tworzone za każdym razem, gdy użytkownik wykona działanie, które utworzy zapytanie db. Nie tylko ze względów wydajnościowych związanych z handshakingiem połączenia, ale także w celu zmniejszenia obciążenia serwera db.

Połączenia DB są cennym towarem, a technika ta pomaga zminimalizować ilość wykorzystaną w danym momencie.

Answer 3

Można chcieć użyć singletonu z powodu ograniczeń serwera bazy danych, na przykład serwer może ograniczyć liczbę połączeń.

Moim głównym powodem jest to, że wiesz, jakie połączenia mogą być zarządzane/zamykane itp., Po prostu sprawia, że ​​rzeczy są bardziej uporządkowane, gdy nie masz niepotrzebnych, nadmiarowych połączeń.

Answer 4

Nie sądzę, że to prosta odpowiedź. Na przykład na platformie ASP.NET platforma domyślnie stosuje pulę połączeń, więc automatycznie dostosowuje "pulę" połączeń i ponownie je wykorzystuje, aby nie tworzyć i nie niszczyć drogich obiektów.

Załóżmy jednak, że piszesz aplikację do zbierania danych, która monitorowała 200 oddzielnych źródeł wejściowych. Za każdym razem, gdy jedno z tych wejść uległo zmianie, odpalasz wątek, który zapisuje zdarzenie do bazy danych. Powiedziałbym, że może to być zły projekt, jeśli istnieje szansa, że ​​nawet ułamek z nich może wystrzelić w tym samym czasie. Nagle posiadanie 20 lub 40 aktywnych połączeń z bazą danych jest nieefektywne. Lepszym rozwiązaniem może być kolejkowanie aktualizacji i tak długo, jak w kolejce są aktualizacje, połączenie singleton wybiera je z kolejki i wykonuje je na serwerze. Jest bardziej wydajny, ponieważ musisz tylko raz negocjować połączenie i uwierzytelnianie. Gdy przez jakiś czas nie będzie aktywności, możesz zamknąć połączenie. Takie zachowanie byłoby trudne do wdrożenia bez centralnego menedżera zasobów, takiego jak singleton.

Answer 5

"tylko jedno aktywne połączenie" to bardzo wąska instrukcja dla ilustracji. Równie dobrze mógłby to być singleton zarządzający pulą połączeń. Punkt singleton dla połączeń z bazami danych polega na tym, że nie chcesz, aby każdy konsument tworzył własne połączenie lub zestaw połączeń.

Answer 6

Myślę, że możesz chcieć być bardziej szczegółowym, "używając singletona do kontrolowania połączenia db w twojej aplikacji internetowej." Idealnie, obiekt java.sql.Connection będzie nie być bezpieczne wątku, ale twój javax.sql.DataSource może chcieć połączyć połączenia, więc powinieneś udać się do jednej instancji, aby udostępnić pulę.

Answer 7

Aplikacje internetowe o wysokiej wydajności (lub nawet średniej wydajności) korzystają z bazy danych connection pooling, więc jedno połączenie DB można udostępnić wielu żądaniom internetowym. Singleton jest zwykle obiektem, który zarządza tą pulą. Myślę, że motywacja do używania singletonu jest odporna na idiotów przeciwko programistom konserwacji, którzy w przeciwnym razie mogliby niepotrzebnie wytworzyć wiele z tych obiektów.

Answer 8

szukasz więcej połączeń dla jednego żądania, a nie jednego połączenia dla całej aplikacji. Nadal można kontrolować dostęp do niego przez singleton (przechowywanie połączenia w kolekcji HttpContext.Items).

Answer 9

"ma to zapewnić, że zawsze będzie aktywne tylko jedno połączenie z bazą danych." Myślę, że lepiej byłoby powiedzieć, że każdy KLIENT ma tylko jedno aktywne połączenie z Twoim DB. Powodem, dla którego jest to niezwykle ważne, jest to, że chcesz zapobiec zakleszczeniom. Jeśli mam DWÓCH otwartych połączeń z bazami danych (jako klient), mogę być aktualizowany na jednym połączeniu, wtedy mógłbym spróbować zaktualizować ten sam wiersz w innym połączeniu. To będzie impas, którego baza danych nie może wykryć. Tak więc idea singletonu polega w zasadzie na tym, aby istniał JEDEN obiekt, który jest odpowiedzialny za przekazywanie połączeń z bazą danych każdemu klientowi. Gruntownie. Nie musisz mieć singla na ten temat, ale większość ludzi powie ci, że ma sens, że system ma tylko jeden.

Answer 10

Założenie Java tutaj, ale jest również istotne dla większości innych technologii.

Nie jestem pewien, czy pomyliłeś użycie zwykłego singletonu z service locator. Oba są wzorami projektowymi. Wzorzec lokalizatora usług jest używany przez aplikacje w celu zapewnienia, że ​​istnieje jedna klasa odpowiedzialna za uzyskanie i zapewnienie dostępu do baz danych, plików, kolejek JMS, itp.

Większość lokalizatorów usług jest wykonywanych jako pojedyncza, ponieważ istnieje nie ma potrzeby, aby wiele lokalizatorów usług wykonywało tę samą pracę. Poza tym przydatne jest buforowanie informacji uzyskanych z pierwszego wyszukiwania, które później mogą być wykorzystane przez innych klientów lokalizatora usług.

Nawiasem mówiąc, argument o

"jest to, aby zapewnić, że zawsze jest tylko jedno aktywne połączenie z DB"

jest fałszywe i wprowadzające w błąd. Jest całkiem możliwe, że połączenie może zostać zamknięte/odzyskane, jeśli pozostanie nieaktywne przez dość długi czas. Dlatego buforowanie połączenia z bazą danych jest niezadowolone. Jest jedno odchylenie od tego argumentu; "ponowne używanie" połączenia uzyskanego z puli połączeń jest zalecane, o ile działa to w tym samym kontekście, tj. w ramach tego samego żądania HTTP lub żądania użytkownika (w zależności od tego, która z nich dotyczy). Dokonuje się tego oczywiście z punktu widzenia wydajności, ponieważ ustanowienie nowych połączeń może okazać się kosztowną operacją.