#java #programowanie #jdbc Kumpel w pracy mówi, że używajac #c3p0 nie trzeba zamykać połączeń. Patrze w kod a on pobiera za kazdym razem połączenie, robi commit i nie robi close po każdym użyciu datasource...dopiero przy wyłączeniu aplikacji robi connection.close(). Pool ustawiony na max : 1 min : 1... Tak mnie zamotał że nie wiem gdzie lewa a gdzie prawa. To jest (chyba) złe podejście co? Bo już zgłupiałem ( ͡°ʖ̯͡°). Mówię, że przy wielu użytkowniakach to się będzie sypać, a on mi na to że przy wielu użytkownikach trzeba parować connection jdbc z użytkownikiem. WAT?
Mówię, że przy wielu użytkowniakach to się będzie sypać, a on mi na to że przy wielu użytkownikach trzeba parować connection jdbc z użytkownikiem.
@CortesHernan: eeee... Cała rola c3p0 polega na tym, że otwierasz i zamykasz połączenie często - ale fizycznie te połączenia nie są zamykane i leza sobie w puli...
@edgar_k: no właśnie wiem, dlatego nie rozumiem jego toku rozumowania. To parowanie to on uważa że klient powinien zawsze dostawać te samo połączenie z puli bo to zapewni spójność danych.
@CortesHernan: nie mam pojęcia co ten twój znajomy bierze, ale c3p0 robi pulę, i jak potrzebujesz sobie z puli to bierzesz, a później powinieneś oddać, ot co cała filozofia.
@NiebieskaSowa: @edgar_k: twierdzi uparcie, że to jedyny sposób uzyskania spójności danych i nie utraty danych przy zapisie z dwóch wątków jednocześnie. Trzymanie connection za jaja żeby drugi wątek nie mógł się do tego dobrać.
@edgar_k: no właśnie chodzi o to, że robi transakcje. :P getConnection(); statement . query ... commit();
i dwa wątki takie coś wykonuja. Mówi ze to kolejkowanie transakcji. Mam mało doświadczenia, nie uważam się za eksperta, ale to mi śmierdzi na kilometr ;p
i dwa wątki takie coś wykonuja. Mówi ze to kolejkowanie transakcji.
@CortesHernan: Jak masz dwie transakcje na tych samych danych to zalezy jakie masz lock level - albo sie jedna wywali albo będzie czekać. Jaki to ma związek z połączeniem to nie mam pojecia, raczej nijaki...
@CortesHernan: nie wiem za bardzo co ma ilość wątków do połączenia z bazą danych, ale spoko nie ma sensu się z tym twoim kolegą przepychać, pamiętaj że w branży IT jest wieeeele takich ludzi którzy mają przekonanie że tylko oni się znają na wszystkim a reszta to debile, najlepiej z takimi nie dyskutować bo to nie ma sensu :) pozdrawiam cumplu.
@NiebieskaSowa: Mma dopiero 2 lata "doswiadczenia" ale praktycznie od zera. W firmie nie stricte informatycznej. Koles ma dużą wiedze i tym mnie zaskoczył. Generalnie wiem, że zawsze powinno się zamykać zasoby zwiazane z jdbc.
Generalnie wiem, że zawsze powinno się zamykać zasoby zwiazane z jdbc.
@NiebieskaSowa @CortesHernan: No chyba, że masz connection pool, z którego pobierasz połączenie kiedy potrzebujesz coś zrobić. Wtedy pool dba o to aby mieć kilka aktywnych połączeń (bo koszt nawiązania połączenia jest duży). Po użyciu oddajesz connection do poola. W tym sensie nie zamykasz połączeń faktycznie.
Parowanie connectiona z użytkownikiem to raczej zły pomysł :) Niestety kolega może mieć TROCHĘ racji ze spójnością danych. Nie wiem jakiej bazy danych używacie, ale jeśli to jest MySQL i jeśli działa w klastrze Galery to wiem z mojego smutnego doświadczenia, że może się zdarzyć, że mimo, iż transakcja się skończyła to przez kilka(dziesiąt) milisekund w innych połączeniach mogą być zaserwowane
Kumpel w pracy mówi, że używajac #c3p0 nie trzeba zamykać połączeń. Patrze w kod a on pobiera za kazdym razem połączenie, robi commit i nie robi close po każdym użyciu datasource...dopiero przy wyłączeniu aplikacji robi connection.close(). Pool ustawiony na max : 1 min : 1... Tak mnie zamotał że nie wiem gdzie lewa a gdzie prawa. To jest (chyba) złe podejście co? Bo już zgłupiałem ( ͡° ʖ̯ ͡°). Mówię, że przy wielu użytkowniakach to się będzie sypać, a on mi na to że przy wielu użytkownikach trzeba parować connection jdbc z użytkownikiem.
WAT?
@CortesHernan: eeee... Cała rola c3p0 polega na tym, że otwierasz i zamykasz połączenie często - ale fizycznie te połączenia nie są zamykane i leza sobie w puli...
@CortesHernan: ( ͡º ͜ʖ͡º) Czy to jakies zajęcia w gimnazjum czy co?
@CortesHernan: Ale powiedz mu, że jest coś takiego jak transakcja w bazie danych..
getConnection();
statement . query ...
commit();
i dwa wątki takie coś wykonuja. Mówi ze to kolejkowanie transakcji. Mam mało doświadczenia, nie uważam się za eksperta, ale to mi śmierdzi na kilometr ;p
@CortesHernan: Jak masz dwie transakcje na tych samych danych to zalezy jakie masz lock level - albo sie jedna wywali albo będzie czekać. Jaki to ma związek z połączeniem to nie mam pojecia, raczej nijaki...
@CortesHernan: i słusznie. Nie ma nic gorszego niż tacy ludzie (znaczy przekonani o swoim błędnym rozumowaniu)
@CortesHernan: amen, więcej nie trzeba mówić.
@NiebieskaSowa @CortesHernan: No chyba, że masz connection pool, z którego pobierasz połączenie kiedy potrzebujesz coś zrobić. Wtedy pool dba o to aby mieć kilka aktywnych połączeń (bo koszt nawiązania połączenia jest duży). Po użyciu oddajesz connection do poola. W tym sensie nie zamykasz połączeń faktycznie.
Parowanie connectiona z użytkownikiem to raczej zły pomysł :)
Niestety kolega może mieć TROCHĘ racji ze spójnością danych. Nie wiem jakiej bazy danych używacie, ale jeśli to jest MySQL i jeśli działa w klastrze Galery to wiem z mojego smutnego doświadczenia, że może się zdarzyć, że mimo, iż transakcja się skończyła to przez kilka(dziesiąt) milisekund w innych połączeniach mogą być zaserwowane
Pool ustawiony na min : 1 max :1 ;)