Grona >> Java >>

zarządzanie połączeniami z ...

Java [1242]

Zapisz się

zarządzanie połączeniami z bazą

  • 1
  • 2
Dodaj kartkę Dodaj bana
Powód wlepienia kartki
Wybierz wątek docelowy z listy lub wpisz jego ID

  • Anonim

    w serwlety itp bawię się od niedawna...i wyczytałem, że w przypadku serwletów, tudzież jsp, nawiązywanie połączeń z bazą danych jest dość "kosztowne", co w moim rozumieniu znaczy mniej więcej tyle, że nawiązywanie połączenia z bazą przy każdej obsłudze żadania i potem zamykanie go jest raczej słabym rozwiązaniem, dlatego też zapewne należy nawiązać sobie jedno lub więcej połączeń stosownie do potrzeb aplikacji i korzystać z nich przez cały czas "życia" aplikacji

    rodzi się zatem w mej głowie pytanie, gdzie takie połączenie/a sobie przechować po jego nawiązaniu i jedynym rozwiązaniem jakie w tym momencie przychodzi mi na myśl jest przechowywanie wspomnianych połączeń w jakimś bean'ie o zasięgu aplikacji, tak, zeby każdy serwlet mógł sobie korzystać z nawiązanego już wcześniej połączenia (a jeżeli takie jeszcze nie istnieje, to je nawiązać)

    czy takie rozwiązanie jest dobre? dlaczego tak/nie? jak inaczej można rozwiązać ten problem...?

  • Lisek

    Najlepiej zarządzanie połączeniami zrzuć na kontener serwletów (np. Tomcat), potem możesz bez problemów wyciągnąć połączenie z jndi nie martwiąc się o kosztowność tych operacji.

  • Koziołek [brat Javowiec]

    Własna implementacja puli połączeń polega na stworzeniu sobie singletonu z listą połączeń który będzie dawał i zabierał połączenia.
    Dobre ćwiczenie na początek.

  • Maciek Makowski

    Tak, dobre ćwiczenie w stosowaniu anti-patterns.

  • Lisek

    Święta prawda Maćku, po co robić coś co dostaje się z automatu. Poza tym sam singleton nie jest zbyt dobrym wzorcem.

  • Anonim

    poczytalem o tym JNDI i nie widze powodu, dla którego miałbym korzystać z własnych rozwiązań (zapewne dalekich od ideału) skoro mam gotowe i sprawdzone rozwiązanie

  • Koziołek [brat Javowiec]

    >Maciek Makowski napisał
    >Tak, dobre ćwiczenie w stosowaniu anti-patterns.

    antywzorzec... IMO jeżeli ktoś uczy się jakiejś technologii to powinien wiele rzeczy napisać samemu by zrozumieć jak to działa. Ponad to własne implementacje nie zawsze są złe. Pozwalają na dostosowanie rozwiązania do własnych potrzeb.

  • Maciek Makowski

    Nie chodzilo mi o wlasna implementacje, tylko o singletona. Singletony prawie zawsze sa zle.

  • Koziołek [brat Javowiec]

    w tym wypadku zły nie jest :) jego zadanie jest proste. Być jedynym obiektem który zarządza pulą połączeń.
    Wzorzec jest na tyle prosty i nie trzeba użerać się ze skomplikowaną implementacją. Nie w tym rzecz, żeby spędzić tydzień na próbach uruchomienia np. komponentu EJB. Dla uproszczenia "otoczki" zadania używamy singletonu.
    Mój pomysł w tym przypadku to raczej zapoznanie z JDNI/JDBC + pule połączeń niż z super prawidłową implementacją. Na to przyjdzie jeszcze czas.

  • Maciek Makowski

    >w tym wypadku zły nie jest :) jego zadanie jest proste.
    >Być jedynym obiektem który zarządza pulą połączeń.

    To jest wlasnie sytuacja w ktorej singletona nie nalezy stosowac.

  • bartkiller

    Czy singleton nie odzwierciedla bytu, o którym fakt, że jest tylko jeden wynika z samej własności problemu/koncepcji ?

  • Dzemus

    Z wikipedii:

    "Często w aplikacji istnieje potrzeba stworzenia klasy, która posiadałaby wyłącznie jedną instancję. Zwykle związane to jest z zapewnieniem większej wydajności aplikacji, np. przy dostępie do bazy danych, gdzie każde łączenie się z bazą jest dla aplikacji kosztowne, bo wymaga czasochłonnego uwierzytelnienia i autoryzacji. W tym przypadku sensowniej jest stworzyć jeden obiekt przechowujący sesję połączenia i wykorzystać go do przesłania wielu zapytań."

  • Maciek Makowski

    Niezbyt mądry ten cytat. Przede wszystkim to nie "klasa potrzebuje mieć jedną instancję", tylko my potrzebujemy stworzyć jedną instancję klasy w naszej aplikacji. No to twórzmy -- wzorzec singletona do niczego nie jest tu potrzebny. Decyzję o tym, czy jakiś obiekt ma być jedynym w systemie podejmować należy nie na etapie implementacji komponentów, lecz na etapie składania aplikacji z tych komponentów.

    Sporo napisano na temat tego, dlaczego singleton jest zdecydowanie nadużywanym wzorcem, np.:
    http://steve.yegge.googlepages.com/...
    http://blogs.msdn.com/scottdensmore...

    Z moich doświadczeń wynika, że w praktyce największym problemem są testy jednostkowe: singletony na ogół (jak w tym przypadku się proponuje) używane są do modelowania elementów środowiska i w wielu klasach aplikacji następnie statycznie odwołuje się do tychże, co bardzo utrudnia "mocking out" i efektywne testowanie.

    Jedyną sytuacją, w której użycie singletona wydaje mi się uzasadnione, są typy wyliczeniowe z dziedziny "biznesowej" -- Boolean na przykład.

  • Koziołek [brat Javowiec]

    @Maciek singleton przestał być "trendy", "jazzy" czy inna cholerą. W prostych aplikacjach nadal świetnie się sprawdza. Tu chodzi o prostą aplikację.
    Poza tym z drugiego podanego przez ciebie linku wynika że 95% programistów nie potrafi używać singletonów. Wbrew pozorom jest to dość trudny wzorzec, którego trzeba po prostu rozważnie używać.

  • bartkiller

    "Singleton pattern is a throwback to non-OO programming"

    to dobre zdanie, z któregoś z tych linków.

  • Koziołek [brat Javowiec]

    >bartkiller napisał
    >"Singleton pattern is a throwback to non-OO programming"
    >
    >to dobre zdanie, z któregoś z tych linków.

    ok. I co z tego? C jest całkowicie nieobiektowe, ale wszystko jest i tak w nim pisane. Nawet Java :) Śrubkę młotkiem wbijesz, ale po co ? Zresztą pisałem Singleton jest wbrew pozorom bardzo trudny i trzeba umieć go używać.


    ps. zamienia się to w niekończącą się dyskusję o wyższość świąt BN nad świętami WN

  • Maciek Makowski

    > ok. I co z tego?

    Jesli nie jest dla Ciebie jasne, po co programowac obiektowo, to napisz wprost -- postaram sie wyjasnic.

    > ps. zamienia się to w niekończącą się dyskusję o wyższość świąt BN
    > nad świętami WN

    Zeby wniesc zatem troche tresci do tej dyskusji moglbys prosze objasnic:
    1. na czym polega "trudnosc" singletona?
    2. w kontekscie puli polaczen, od ktorej ta dyskusja sie zaczela, jaka jest roznica miedzy zastosowaniem singletona a przechowywaniem polaczen w zmiennej klasowej (statycznej) i zastosowaniem klasowej metody zwracajacej polaczenie, czegos w tym stylu:

    class ConnectionPool {
    private static List<Connection> connections;
    public static Connection getConnection() {
    ...
    }
    ...
    }

  • Koziołek [brat Javowiec]

    1. Trudność singletona leży nie w jego implementacji, a w znalezieniu miejsca w którym można go wykorzystać.

    2. W twoim rozwiązaniu pula połączeń powstaje w momencie uruchomienia aplikacji. W moim:

    class ConnectionPoolSing{
    private static ConnectionPoolSing INSTANCE = null;
    private List<Connection> conns;
    public ConnectionPoolSing getInstance(){
    if(INSTANCE== null)
    INSTANCE = new ConnectionPoolSing();
    return INSTANCE;
    }
    private ConnectionPoolSing(){
    createConnections();
    }
    private createConnections(){...}
    public getConnection(){...}
    }

    pula połączeń powstaje w momencie utworzenia obiektu. Mała rzecz a cieszy. Czasami opóźnienie jakiejś operacji w tym przypadku utworzenia połączeń może być zbawienna. Teraz właśnie wracamy do 1. trzeba zdecydować, które obiekty chcemy opóźniać.
    Kwestia tego co kto lubi.

  • Maciek Makowski

    > 2. W twoim rozwiązaniu pula połączeń powstaje w momencie
    > uruchomienia aplikacji.

    Niby dlaczego? Moje getConnection() moze dzialac tak:

    if (w connections jest nieuzywane polaczenie) {
    conn = nieuzywane polaczenie z connections;
    } else {
    conn = nowe polaczenie;
    dodaj conn do connections;
    }
    oznacz conn jako uzywane;
    return conn;

    Nic nie jest tworzone przy starcie aplikacji, polaczenia otwierane sa dynamicznie tylko wtedy, kiedy sa potrzebne.

    Ponawiam pytanie: jaka przewage ma Twoj singleton nad moimi metodami statycznymi?

    > public ConnectionPoolSing getInstance(){

    Zapomniales o synchronizacji. Takich "singletonow" moze w aplikacji wielowatkowej powstac sporo. Ze statyczna pula nie ma takich problemow, masz gwarancje, ze w danej JVM bedzie tylko jedna -- synchronizowac trzeba tylko pobieranie i zwracanie polaczen.

  • KosciaK

    Poprawcie mnie jeśli pisze głupoty

    Z tego co wiem singleton ma tą przewagę nad klasą statyczną, że może dziedziczyć po jakiejś klasie lub implementować jakiś interfejs. Możemy mieć wiele klas (implementujących określony interfejs i będących singletonami lub dziedziczących po jakiejś klasie abstrakcyjnej by dzielić wspólny kod) o różnych implementacjach zależnie od potrzeb. W przypadku klasy z metodami statycznymi to nie przejdzie i uzależniamy się od określonej implementacji.
  • 1
  • 2