🚀 go-pugleaf

3P pisze:
> Dnia 05-10-2009 o 12:39:10 wloochacz <nospam.wloochacz@nospam.dgbit.pl> 
> napisał(a):
> 
>> 3P pisze:
>> /ciach/
>>
>>> Chyba czegoś nie rozumiesz.
>> Nie sądzę...
>>
>>> Właśnie po to jest connection pooling, abyś zamykał i otwierał 
>>> połączenia bardzo często.
>> Niezupełnie.
>> Connection pooling jest po to, abyś nie musiał robić osobnego 
>> "connection dla każdego zapytania", ot co...
>> A "przy okazji" załatwia w inteligentny (mniej lub bardziej) cykl 
>> życia danego connection, które jest zarządzane pulą.
>> Generalnie mechanizm jest prosty; potrzebujesz connection prosisz pulę 
>> o nie. Ono Ci daje to które jest aktualnie wolne, lub tworzy je dla 
>> Ciebie, kiedy wolnego nie ma.
>> Kiedy connection nie jest Ci potrzebne - wraca do puli i czeka na 
>> następne żądania.
>> Dzięki temu nie musisz się martwić o to, czy dane connection nie jest 
>> zaalokowane przez inne zapytanie.
>>
> Nie rozumiem o czym piszesz w ostatnim zdaniu. A kiedy niby musze się 
> martwić?
Otwórz sobie recordset z kursorem po stornie serwera (nawet w .NET da 
się to zrobić...), nie zamykaj goi do tego samego połączenia (ta sama 
instancja, czyli bez puli) podepnij nową instancję w/w zapytania.
Jak trafisz na komunikat "connection is busy with another resultset", to 
wróć i pogadamy.

Pisałeś kiedykolwiek w czymś innym niż .NET?
Tam gdzie nie było poolingu?

> Jednak nie rozumiesz chyba idei connection poolingu.
Oczywiście.

> Ponieważ zalecaną metodą pracy jest tworzenie połączenia na czas 
> zapytania i zamykanie po jego wykonaniu
Bzdura.
Kto to zaleca w WindowsForms?
Gdzie to jest napisane?
Pokaż proszę.
Nie piszę w .NET i nie piszę app webowych.

> to stosuje się connection pooling, aby nie tracić czasu na tworzenie 
> nowych połączeń. Dzięki temu
> masz cały czas dostępne obiekty połączeń do bazy (tzn. klienci mogą się 
> łączyć do bazy). 
Tak, ale te połączenia i tak zostały stworzone i są utrzymywane przez 
pulę - wszystko dzieje się automatycznie, to całą różnica.

> Dzięki temu
> więcej klientów może pracować równolegle. 
Dzięki czemu? Jak pooling przekłąda się na "więcej klientów"?
Chyba nie rozumiesz idei connection poolingu.

> Connection pooling daje ci 
> tylko to, że szybciej uzyskujesz połączenia.
Niezupełnie szybciej - po prost pula trzyma połączenia, więc dostajesz 
istniejące aktywne połączenie. Jeżeli pula nie ma wolnych aktywnych 
połączeń to musi je utworzyć; tyle że w przypadku MS SQLa utworzenie 
połączenia typu pooled nie wymaga wykonania wszystkich akcji, które są 
wymagane do utworzenia normalnego połączenia - a więc tak, tworzenia 
połączenia typu pooled jest szybsze.

> Gdybyś miał cały czas otwarte połączenia to ConnectionPooling do niczego 
> nie byłby ci potrzebny.
Co Ty nie powiesz?
Jest potrzebny - spróbuj utrzymać połączenie i wykonać jakąś operację, 
ale równolegle w wielu wątkach używając tego samego połączenia (nie puli).
A potem wróć i pochwal się wynikami...

>>> Dzięki temu możesz mieć jednocześnie więcej użytkowników pracujących 
>>> z bazą.
> 
>> Niezupełnie tak - mogę sprawić, aby kod wykonywał się równolegle, a 
>> nie sekwencyjnie. Prawie wszystkie bazy danych, mają kretyńskie 
>> ograniczenie, które nie pozwala mieć aktywnych wielu zestawów danych, 
>> które korzystają z tego samego połączenia. Chlubnym wyjątkiem jest 
>> Firebird (tu można mieć nawet wiele transakcji w tym samym connection 
>> i   nie mam na myśli save pointów) i ciekawą inicjatywą jest MARS 
>> dostępny od MS SQL Server 2005.
>>
> Czy nie widzisz, że piszesz o czymś zupełnie innym? Piszę o wielu 
> użytkownikach jednocześnie, a ty mi tu o MARSie piszesz.
Powiem tak, żebyś zrozumiał; a co gdyby użytkownik był de-facto 
polecenim SQL, a więc chodzi o to, że użytkownicy wykonują polecenia SQL 
za pomocą jednego globalnego connection?

-- 
wloochacz