🚀 go-pugleaf

W dniu 09-09-30 16:18, Jakub Owczarski pisze:
> Teraz chciałbym napisać coś z interfejsem okienkowym(MDI) tylko nie
> wiem nawet jak się za to zabrać.
> Czy trzymać aktywne połączenie przez całe życie programu(jeżeli tak to
> jak i gdzie?)

W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania zapytania. 
Chyba, że to zapytanie to całe życie tego programu :)

> Jak bezpiecznie zaszyć hasło do bazy? w kilku programach spotkałem się
> z rozwiązaniem, że użytkownicy są tworzeni na poziomie bazy - czyli
> każdy nowy użytkownik programu to nowy użytkownik  bazy, takie coś
> pozwoliło by nie trzymać hasła do bazy w programie, ale gdybym chciał
> mieć użytkowników na poziomie aplikacji(używając jednego usera db) a
> nie bazy to jak trzymac to hasło?

Wystarczy je zaszyfrować.

> Moja główna proźba to prosił bym o tytuł(y) jakichś dobrych książek na
> ten temat (C# + windows forms + bazy danych) ale jak by ktoś chciał
> powiedzieć kilka słów na ten temat to też będzie miło.

MSDN.

tm

On Oct 1, 10:16 pm, Tomasz Muszyński <thom...@op.pl_nospam> wrote:

> > Moja główna proźba to prosił bym o tytuł(y) jakichś dobrych książek na
> > ten temat (C# + windows forms + bazy danych) ale jak by ktoś chciał
> > powiedzieć kilka słów na ten temat to też będzie miło.
>
> MSDN.

No w sumie po wysłaniu tego posta też na to wpadłem ;-)
I tak sobie czytam na MSDN wszystko co się da o ADO.NET + windows
forms, ale mimo wszystko lubię mieć papierową książkę do nauki, więc
jeżeli ktoś mógł by polecić coś wartościowego (najlepiej bogatego w
przykłady) to było by miło.
Po lekkim serczu na amazonie znalazłem:
http://www.amazon.com/Professional-ADO-NET-Entity-Framework-Programmer/dp/047018261X/
http://www.amazon.com/Programming-Entity-Framework-Julia-Lerman/dp/059652028X/
http://www.amazon.com/ADO-NET-3-5-Cookbook-Cookbooks-OReilly/dp/0596101406/
Tylko fajnie by było kupić coś "sprawdzonego".

Pozdrawiam i dzięki
Jakub Owczarski

>> Czy trzymać aktywne połączenie przez całe życie programu(jeżeli tak to
>> jak i gdzie?)
>
> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania zapytania.

A tak z ciekawości. Czemu nie?
Zanczy czy są jakieś powody techniczne czy też raczej ideologoczne ;)

Pozdrawiam
Mariusz 

Tomasz Muszyński pisze:
> W dniu 09-09-30 16:18, Jakub Owczarski pisze:
>> Teraz chciałbym napisać coś z interfejsem okienkowym(MDI) tylko nie
>> wiem nawet jak się za to zabrać.
>> Czy trzymać aktywne połączenie przez całe życie programu(jeżeli tak to
>> jak i gdzie?)
> 
> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania zapytania. 
> Chyba, że to zapytanie to całe życie tego programu :)
Dlaczego?
Dla wielu krótkich zapytań, gdzie każde tworzy własne connection i to 
się musi z bazą połączyć (a baza alokuje zasoby dla takiego connection), 
to... doskonały pomysł.
Tak, rewelacja...
No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko np. MS SQL?
Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)

>> Jak bezpiecznie zaszyć hasło do bazy? w kilku programach spotkałem się
>> z rozwiązaniem, że użytkownicy są tworzeni na poziomie bazy - czyli
>> każdy nowy użytkownik programu to nowy użytkownik  bazy, takie coś
>> pozwoliło by nie trzymać hasła do bazy w programie, ale gdybym chciał
>> mieć użytkowników na poziomie aplikacji(używając jednego usera db) a
>> nie bazy to jak trzymac to hasło?
> 
> Wystarczy je zaszyfrować.
No tak.
Tylko, że zawsze można to odszyfrować.
Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
zaszyfrowane dziecinnie łatwo "wysnifować".
A przecież w MS SQL jest takie twór jak Application Role...

/ciach/

-- 
wloochacz

>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania 
>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
> Dlaczego?

Bo to dobra praktyka sprawdzona i pewna

> Dla wielu krótkich zapytań, gdzie każde tworzy własne connection i to 
> się musi z bazą połączyć (a baza alokuje zasoby dla takiego connection), 
> to... doskonały pomysł.
> Tak, rewelacja...

znasz program który robi duzo małych zapytań jeśli taki tworzysz to to 
jest to bardzo dziwne podejście do tematu (robisz zapytanie sqlowe do 
każdego textboxa ? czy raczej bierzesz z bazy to co jest ci potrzebne za 
jenym razem?)

> No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko np. MS SQL?
> Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)

Wszystkich z wyjątkiem  baz objekowch

> No tak.
> Tylko, że zawsze można to odszyfrować.
> Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
> zaszyfrowane dziecinnie łatwo "wysnifować".

Wszystko idzie wysnifować .....

> A przecież w MS SQL jest takie twór jak Application Role...

Istnieje dopóty dopóki nie trafisz na opór materii ludzkiej.

szymo pisze:
>>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania 
>>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
>> Dlaczego?
> 
> Bo to dobra praktyka sprawdzona i pewna
> 
>> Dla wielu krótkich zapytań, gdzie każde tworzy własne connection i to 
>> się musi z bazą połączyć (a baza alokuje zasoby dla takiego 
>> connection), to... doskonały pomysł.
>> Tak, rewelacja...
> 
> znasz program który robi duzo małych zapytań jeśli taki tworzysz to to 
> jest to bardzo dziwne podejście do tematu (robisz zapytanie sqlowe do 
> każdego textboxa ? czy raczej bierzesz z bazy to co jest ci potrzebne za 
> jenym razem?)
Oczywiście, że znam taki - każde pierdnięcie skutkuje wywołanie SP.
Nie, nie ja go napisałem - ja tylko pokazałem jego "twórcy", że ten sam 
raport który u niego mieli się kilka godzin, można napisać tak, że zrobi 
to kilkaset razy szybciej; oczywiście, to żaden argument - wszystko 
można spartolić...

Wracając do tematu, takie podejście jest standardowe w aplikacjach 
webowych, ale w WindowsForms, gdzie aplikacja działa (zzwyczaj) w trybie 
state full?
Po co?
Zrozumiałbym jeszcze takie podejście, gdzie jest automatycznie 
zarządzana pula połączeń - wtedy, ok.
Lecz jeżeli tego nie ma, to zbytnie szafowanie zasobami serwera - imo.

>> No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko np. MS 
>> SQL?
>> Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)
> 
> Wszystkich z wyjątkiem  baz objekowch
Masz na myśli obiektowych? A jakie to ma znaczenie, czy to baza 
obiektowa, relacyjna czy relacyjna-obiektowa?

>> No tak.
>> Tylko, że zawsze można to odszyfrować.
>> Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
>> zaszyfrowane dziecinnie łatwo "wysnifować".
> 
> Wszystko idzie wysnifować .....
To nie jest argument. Żaden.

>> A przecież w MS SQL jest takie twór jak Application Role...
> 
> Istnieje dopóty dopóki nie trafisz na opór materii ludzkiej.
A tego nie rozumiem - co to ma do rzeczy?

-- 
wloochacz

szymo pisze:
>>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania 
>>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
>> Dlaczego?
> 
> Bo to dobra praktyka sprawdzona i pewna
Zapomniałem odnieść się do tego :)
A więc, dlaczego ta praktyka jest taka dobra i pewna w czym?

/ciach/

-- 
wloochacz

> Oczywiście, że znam taki - każde pierdnięcie skutkuje wywołanie SP.
> Nie, nie ja go napisałem - ja tylko pokazałem jego "twórcy", że ten sam 
> raport który u niego mieli się kilka godzin, można napisać tak, że zrobi 
> to kilkaset razy szybciej; oczywiście, to żaden argument - wszystko 
> można spartolić...

Zaiste w pełni się zgadzam :)


>>> No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko np. 
>>> MS SQL?
>>> Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)
>>
>> Wszystkich z wyjątkiem  baz objekowch
> Masz na myśli obiektowych? A jakie to ma znaczenie, czy to baza 
> obiektowa, relacyjna czy relacyjna-obiektowa?

Obiektowa - ma znaczenie.
> 
>>> No tak.
>>> Tylko, że zawsze można to odszyfrować.
>>> Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
>>> zaszyfrowane dziecinnie łatwo "wysnifować".
>>
>> Wszystko idzie wysnifować .....
> To nie jest argument. Żaden.

To bardzo mocny argument.
> 
>>> A przecież w MS SQL jest takie twór jak Application Role...
>>
>> Istnieje dopóty dopóki nie trafisz na opór materii ludzkiej.
> A tego nie rozumiem - co to ma do rzeczy?

W sumie nic do póki nie trafisz na administratora troglodytę, który sql 
server traktuje jak czasrne pudełko lub maszynę która robi "pik" jak w 
monty-pythonie lub też trafisz na innego zboczeńca który powie bo nie.
Poza tym ograniczasz się tymsamym do MSsql.

wloochacz pisze:
> szymo pisze:
>>>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania 
>>>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
>>> Dlaczego?
>>
>> Bo to dobra praktyka sprawdzona i pewna
> Zapomniałem odnieść się do tego :)
> A więc, dlaczego ta praktyka jest taka dobra i pewna w czym?
> 
> /ciach/
> 

po to aby nie trzymać połączenia kiedy nic nie jest wysyłane ?
po to by szanować czas serwera i jego zasoby ?

szymo pisze:
>> Oczywiście, że znam taki - każde pierdnięcie skutkuje wywołanie SP.
>> Nie, nie ja go napisałem - ja tylko pokazałem jego "twórcy", że ten 
>> sam raport który u niego mieli się kilka godzin, można napisać tak, że 
>> zrobi to kilkaset razy szybciej; oczywiście, to żaden argument - 
>> wszystko można spartolić...
> 
> Zaiste w pełni się zgadzam :)
> 
> 
>>>> No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko np. 
>>>> MS SQL?
>>>> Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)
>>>
>>> Wszystkich z wyjątkiem  baz objekowch
>> Masz na myśli obiektowych? A jakie to ma znaczenie, czy to baza 
>> obiektowa, relacyjna czy relacyjna-obiektowa?
> 
> Obiektowa - ma znaczenie.
Jakie?
Nie znam się, to pytam...

>>>> No tak.
>>>> Tylko, że zawsze można to odszyfrować.
>>>> Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
>>>> zaszyfrowane dziecinnie łatwo "wysnifować".
>>>
>>> Wszystko idzie wysnifować .....
>> To nie jest argument. Żaden.
> 
> To bardzo mocny argument.
Eee.. tam; chodziło mi o poziom wymaganej wiedzy do złamania danego 
sposobu autoryzacji - tu jest prosto, inne sposoby dają wyższe poziomy 
bezpieczeństwa. Po prostu nie jest tak hop-sip - zainstalować Wireshark 
i lux.


>>>> A przecież w MS SQL jest takie twór jak Application Role...
>>>
>>> Istnieje dopóty dopóki nie trafisz na opór materii ludzkiej.
>> A tego nie rozumiem - co to ma do rzeczy?
> 
> W sumie nic do póki nie trafisz na administratora troglodytę, który sql 
> server traktuje jak czasrne pudełko lub maszynę która robi "pik" jak w 
> monty-pythonie lub też trafisz na innego zboczeńca który powie bo nie.
> Poza tym ograniczasz się tymsamym do MSsql.
To "tylko" zmiana sposobu autoryzacji - przy dobrze zaprojektowanym 
systemie do "pikuś" :)

>>>>> No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko np. 
>>>>> MS SQL?
>>>>> Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)
>>>>
>>>> Wszystkich z wyjątkiem  baz objekowch
>>> Masz na myśli obiektowych? A jakie to ma znaczenie, czy to baza 
>>> obiektowa, relacyjna czy relacyjna-obiektowa?
>>
>> Obiektowa - ma znaczenie.
> Jakie?
> Nie znam się, to pytam...

Obiektowe bazy danym cnają to do siebie że są obiektowe ? i
objekty.mająswojemetody
albo
objekty.mająKolekcjeObjektów.ktremająobiekty(0).imająmetody()
które w momencie sejw jeżdzą po wielu "tabelach" i czasem zapisanie 
czegoś poniżej wymaga otwartego połącznia do bazy które czasem lepiej 
jest potrzymać dłużej,  bo twój jeden zapis po stronie kodu może 
powodować wiele zapisów po stronie bazy -ot relacje.
> 
>>>>> No tak.
>>>>> Tylko, że zawsze można to odszyfrować.
>>>>> Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
>>>>> zaszyfrowane dziecinnie łatwo "wysnifować".
>>>>
>>>> Wszystko idzie wysnifować .....
>>> To nie jest argument. Żaden.
>>
>> To bardzo mocny argument.
> Eee.. tam; chodziło mi o poziom wymaganej wiedzy do złamania danego 
> sposobu autoryzacji - tu jest prosto, inne sposoby dają wyższe poziomy 
> bezpieczeństwa. Po prostu nie jest tak hop-sip - zainstalować Wireshark 
> i lux.

można zainstalować fidlera, .Net Reflektora  lub inne dziadowskie 
oprogramowanie i jak będziesz chciał się dowiedzieć na pewno się 
dowiesz. Poza tym jak chcesz już na prawdę być bezpieczny to przesyłasz 
dane https'em przez webservice czy inaczej modnym skąd inąd serwisem 
ostatnio WCF'owym do aplikacji Windows a nie kombinujesz z Conection 
Stringami po stronie aplikacji Windows - one nie są tam potrzebne do życia.
> 
> 
>>>>> A przecież w MS SQL jest takie twór jak Application Role...
>>>>
>>>> Istnieje dopóty dopóki nie trafisz na opór materii ludzkiej.
>>> A tego nie rozumiem - co to ma do rzeczy?
>>
>> W sumie nic do póki nie trafisz na administratora troglodytę, który 
>> sql server traktuje jak czasrne pudełko lub maszynę która robi "pik" 
>> jak w monty-pythonie lub też trafisz na innego zboczeńca który powie 
>> bo nie.
>> Poza tym ograniczasz się tymsamym do MSsql.
> To "tylko" zmiana sposobu autoryzacji - przy dobrze zaprojektowanym 
> systemie do "pikuś" :)

żebyś wiedział kolego jaki ten pikuś potrafi być gigantyczny i nie do 
przeskoczenia w realnym świecie - jak ci się jeden z drugi uprze. Owszem
implementacja pikuś,

szymo pisze:
> wloochacz pisze:
>> szymo pisze:
>>>>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania 
>>>>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
>>>> Dlaczego?
>>>
>>> Bo to dobra praktyka sprawdzona i pewna
>> Zapomniałem odnieść się do tego :)
>> A więc, dlaczego ta praktyka jest taka dobra i pewna w czym?
>>
>> /ciach/
>>
> 
> po to aby nie trzymać połączenia kiedy nic nie jest wysyłane ?
> po to by szanować czas serwera i jego zasoby ?
Od tego nie jest connection poooling, a nie "osobne connection na każde 
zapytanie" - toż to masakra jest!!

-- 
wloochacz

wloochacz pisze:
> szymo pisze:
>> wloochacz pisze:
>>> szymo pisze:
>>>>>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania 
>>>>>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
>>>>> Dlaczego?
>>>>
>>>> Bo to dobra praktyka sprawdzona i pewna
>>> Zapomniałem odnieść się do tego :)
>>> A więc, dlaczego ta praktyka jest taka dobra i pewna w czym?
>>>
>>> /ciach/
>>>
>>
>> po to aby nie trzymać połączenia kiedy nic nie jest wysyłane ?
>> po to by szanować czas serwera i jego zasoby ?
> Od tego nie jest connection poooling, a nie "osobne connection na każde 
> zapytanie" - toż to masakra jest!!
> 
polecam artykuł
http://developers.pl/blogs/ucel/archive/2006/11/16/jak-to-jest-z-connection-pooling.aspx

szymo pisze:
> 
>>>>>> No i cz w/w uwaga dotyczy wszelkiej maści baz danych, czy tylko 
>>>>>> np. MS SQL?
>>>>>> Jakoś nie mogę się odczepić od związków, że jeśli .NET to MS SQL :)
>>>>>
>>>>> Wszystkich z wyjątkiem  baz objekowch
>>>> Masz na myśli obiektowych? A jakie to ma znaczenie, czy to baza 
>>>> obiektowa, relacyjna czy relacyjna-obiektowa?
>>>
>>> Obiektowa - ma znaczenie.
>> Jakie?
>> Nie znam się, to pytam...
> 
> Obiektowe bazy danym cnają to do siebie że są obiektowe ? i
> objekty.mająswojemetody
> albo
> objekty.mająKolekcjeObjektów.ktremająobiekty(0).imająmetody()
> które w momencie sejw jeżdzą po wielu "tabelach" i czasem zapisanie 
> czegoś poniżej wymaga otwartego połącznia do bazy które czasem lepiej 
> jest potrzymać dłużej,  bo twój jeden zapis po stronie kodu może 
> powodować wiele zapisów po stronie bazy -ot relacje.
Nie zgadzam się.
Pytałem dlaczego to niby obiektowe bazy danych mają trzymać połąćzenie, 
a Ty nam tu (w potężnym skrócie i uproszczeniu) opisałeś mechanizm 
mapowania obiektowo relacyjnego; ORM nam opisałeś, a to nie ma nic 
wspólnego z "obiektową bazą danych".

>>>>>> No tak.
>>>>>> Tylko, że zawsze można to odszyfrować.
>>>>>> Poza tym, jeżeli łącze z bazą nie będzie szyfrowane, to takie 
>>>>>> zaszyfrowane dziecinnie łatwo "wysnifować".
>>>>>
>>>>> Wszystko idzie wysnifować .....
>>>> To nie jest argument. Żaden.
>>>
>>> To bardzo mocny argument.
>> Eee.. tam; chodziło mi o poziom wymaganej wiedzy do złamania danego 
>> sposobu autoryzacji - tu jest prosto, inne sposoby dają wyższe poziomy 
>> bezpieczeństwa. Po prostu nie jest tak hop-sip - zainstalować 
>> Wireshark i lux.
> 
> można zainstalować fidlera, .Net Reflektora  lub inne dziadowskie 
> oprogramowanie i jak będziesz chciał się dowiedzieć na pewno się 
> dowiesz. Poza tym jak chcesz już na prawdę być bezpieczny to przesyłasz 
> dane https'em przez webservice czy inaczej modnym skąd inąd serwisem 
> ostatnio WCF'owym do aplikacji Windows a nie kombinujesz z Conection 
> Stringami po stronie aplikacji Windows - one nie są tam potrzebne do życia.
Ale są proste i skuteczne, poza tym to naprawdę zależy co się tam 
pisze... Nie wszędzie jest potrzebna architektura komponentowa, a zwykły 
connection string wystarczy - przy jakiejś małej aplikacyjce...

>>>>>> A przecież w MS SQL jest takie twór jak Application Role...
>>>>>
>>>>> Istnieje dopóty dopóki nie trafisz na opór materii ludzkiej.
>>>> A tego nie rozumiem - co to ma do rzeczy?
>>>
>>> W sumie nic do póki nie trafisz na administratora troglodytę, który 
>>> sql server traktuje jak czasrne pudełko lub maszynę która robi "pik" 
>>> jak w monty-pythonie lub też trafisz na innego zboczeńca który powie 
>>> bo nie.
>>> Poza tym ograniczasz się tymsamym do MSsql.
>> To "tylko" zmiana sposobu autoryzacji - przy dobrze zaprojektowanym 
>> systemie do "pikuś" :)
> 
> żebyś wiedział kolego jaki ten pikuś potrafi być gigantyczny i nie do 
> przeskoczenia w realnym świecie - jak ci się jeden z drugi uprze. Owszem
> implementacja pikuś,
Napisałem - dobrze zaprojektowany system, to np. taki który potrafi 
autoryzować się za pomocą różnych metod i kanałów (WebService, baz 
danych, serwer aplikacyjny czy cokolwiek innego). Interfejs 
autoryzacyjny jest taki sam - implementacje różne.
Jak facio chce appRole - spoko, odpowiedni plugin i szlus.
Jeżeli chce WS - tak samo i analogicznie dalej. To naprawdę nie jest 
trudne do zrobienia - podkreślam, mam na myśli tylko i wyłącznie 
mechanizm autoryzacji.

-- 
wloochacz

> można zainstalować fidlera, .Net Reflektora  lub inne dziadowskie  
> oprogramowanie i jak będziesz chciał się dowiedzieć na pewno się  
> dowiesz. Poza tym jak chcesz już na prawdę być bezpieczny to przesyłasz  
> dane https'em przez webservice czy inaczej modnym skąd inąd serwisem  
> ostatnio WCF'owym do aplikacji Windows a nie kombinujesz z Conection  
> Stringami po stronie aplikacji Windows - one nie są tam potrzebne do  
> życia.

A co to ma wspólnego z aplikacja Windows Forms? Zresztą wtedy wystarczy  
się dostać do serwera z danymi.
Nie ma zupełnie nic złego w bezpośrednim łączeniu się do bazy.  
Zastosowanie Web Service'ów, WCF ma wynikać
z potrzeb, a nie po to żeby programista mógł zaszpanować jakiej to  
technologii nie zna.

Dnia 02-10-2009 o 15:57:07 wloochacz <nospam.wloochacz@nospam.dgbit.pl>  
napisał(a):

> szymo pisze:
>> wloochacz pisze:
>>> szymo pisze:
>>>>>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania  
>>>>>> zapytania. Chyba, że to zapytanie to całe życie tego programu :)
>>>>> Dlaczego?
>>>>
>>>> Bo to dobra praktyka sprawdzona i pewna
>>> Zapomniałem odnieść się do tego :)
>>> A więc, dlaczego ta praktyka jest taka dobra i pewna w czym?
>>>
>>> /ciach/
>>>
>>  po to aby nie trzymać połączenia kiedy nic nie jest wysyłane ?
>> po to by szanować czas serwera i jego zasoby ?
> Od tego nie jest connection poooling, a nie "osobne connection na każde  
> zapytanie" - toż to masakra jest!!
>
Chyba czegoś nie rozumiesz. Właśnie po to jest connection pooling, abyś  
zamykał i otwierał połączenia bardzo często.
Dzięki temu możesz mieć jednocześnie więcej użytkowników pracujących z  
bazą.

> http://www.amazon.com/Programming-Entity-Framework-Julia-Lerman/dp/059652028X/

To i nic więcej na temat nie trzeba. Zobacz opinie. Polecają ją też ludzie  
z MS.

Dnia 02-10-2009 o 18:54:44 3P <nospam@serwer.pl> napisał(a):

>
>> http://www.amazon.com/Programming-Entity-Framework-Julia-Lerman/dp/059652028X/
>
> To i nic więcej na temat nie trzeba. Zobacz opinie. Polecają ją też  
> ludzie z MS.

Oczywiście jeżeli chcesz programować z wykorzystaniem EntityFramework.

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.

> 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.

-- 
wloochacz

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ć?
Jednak nie rozumiesz chyba idei connection poolingu.

Ponieważ zalecaną metodą pracy jest tworzenie połączenia na czas zapytania  
i zamykanie po jego wykonaniu
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). Dzięki temu
więcej klientów może pracować równolegle. Connection pooling daje ci tylko  
to, że szybciej uzyskujesz połączenia.
Gdybyś miał cały czas otwarte połączenia to ConnectionPooling do niczego  
nie byłby ci potrzebny.

>> 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.

MJK wrote:
>>> Czy trzymać aktywne połączenie przez całe życie programu(jeżeli tak
>>> to jak i gdzie?)
>>
>> W żadnym wypadku! Połączenie tworzysz tylko na czas wykonania
>> zapytania.
>
> A tak z ciekawości. Czemu nie?
> Zanczy czy są jakieś powody techniczne czy też raczej ideologoczne ;)

Serwer bazy danych ma ograniczoną liczbę połaczeń, które może mieć na raz 
otwarte. Wynika to głównie z przyczyn sprzętowych (wielkość pamięci) ale też 
czasami z licencyjnych. Poza tym od kiedy wymyślono Connection Pooling 
trzymanie otwartych połączeń nie ma najmniejszego sensu.
yamma 

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

wloochacz wrote:
> 3P pisze:

>> 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ę.

http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
"We strongly recommend that you always close the connection when you are 
finished using it so that the connection will be returned to the pool. You 
can do this using either the Close or Dispose methods of the Connection 
object, or by opening all connections inside a using statement in C#, or a 
Using statement in Visual Basic. Connections that are not explicitly closed 
might not be added or returned to the pool."
yamma 

yamma pisze:
> wloochacz wrote:
>> 3P pisze:
> 
>>> 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ę.
> 
> http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
> "We strongly recommend that you always close the connection when you are 
> finished using it so that the connection will be returned to the pool. 
> You can do this using either the Close or Dispose methods of the 
> Connection object, or by opening all connections inside a using 
> statement in C#, or a Using statement in Visual Basic. Connections that 
> are not explicitly closed might not be added or returned to the pool."
Tu jest napisane, że oni mocno zalecają zamykanie nieużywanego 
połączenia, żeby wróciło do puli.
A nie tego, że mocno zalecają używania connection pooling.

Żeby była jasność; Connection Pooling w ADO.NET przy połączeniach z SQL 
Server jest bardzo OK i absolutnie nie jestem jej przeciwnikiem.
Ale nie jest to globalna zasada, która dotyczy wszystkiego i w każdej 
sytuacji.

-- 
wloochacz

wloochacz wrote:
> yamma pisze:
>> wloochacz wrote:
>>> 3P pisze:
>>
>>>> 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ę.
>>
>> http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
>> "We strongly recommend that you always close the connection when you
>> are finished using it so that the connection will be returned to the
>> pool. You can do this using either the Close or Dispose methods of
>> the Connection object, or by opening all connections inside a using
>> statement in C#, or a Using statement in Visual Basic. Connections
>> that are not explicitly closed might not be added or returned to the
>> pool."
> Tu jest napisane, że oni mocno zalecają zamykanie nieużywanego
> połączenia, żeby wróciło do puli.
> A nie tego, że mocno zalecają używania connection pooling.

Nie wiem jak inni ale ja odnoszę wrażenie, że dyskutujesz z samym sobą. 
Pytanie było o to, czy trzymać aktywne połączenie przez cały czas życia 
programu. Ty się czepiłeś tematu baza z Connection Poolingiem vs baza bez 
Connection Poolingu, w dodatku podając jako argumenty sytuacje dość 
ekstremalne i wynikające raczej z niekompetencji architekta aplikacji. 
Wiesz, my tutaj w wiekszości wiemy co to jest Connection Pooling i nie 
musisz nas uświadamiać. :-) Ja w każdym bądź razie nie zamierzam o tym 
dyskutować. Ja tylko odpowiedziałem na twoje pytanie o to, gdzie to jest 
napisane.
yamma 

yamma pisze:
> wloochacz wrote:
>> yamma pisze:
>>> wloochacz wrote:
>>>> 3P pisze:
>>>
>>>>> 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ę.
>>>
>>> http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
>>> "We strongly recommend that you always close the connection when you
>>> are finished using it so that the connection will be returned to the
>>> pool. You can do this using either the Close or Dispose methods of
>>> the Connection object, or by opening all connections inside a using
>>> statement in C#, or a Using statement in Visual Basic. Connections
>>> that are not explicitly closed might not be added or returned to the
>>> pool."
>> Tu jest napisane, że oni mocno zalecają zamykanie nieużywanego
>> połączenia, żeby wróciło do puli.
>> A nie tego, że mocno zalecają używania connection pooling.
> 
> Nie wiem jak inni ale ja odnoszę wrażenie, że dyskutujesz z samym sobą. 
Zgadzam się ;-)

> Pytanie było o to, czy trzymać aktywne połączenie przez cały czas życia 
> programu. Ty się czepiłeś tematu baza z Connection Poolingiem vs baza 
> bez Connection Poolingu, w dodatku podając jako argumenty sytuacje dość 
> ekstremalne i wynikające raczej z niekompetencji architekta aplikacji. 
Mhm... niech Ci będzie; tzn - tak, przykłady są skrajne i być może, 
naciągane - zwłaszcza w kontekście grupy (.NET), ale z ta niekompetencją 
to chyba nie do końca się rozumiemy.

> Wiesz, my tutaj w wiekszości wiemy co to jest Connection Pooling i nie 
> musisz nas uświadamiać. :-) 
OK, nie będę. Ale dalej podtrzymuje swoje stanowisko - w przytoczonym 
przez Ciebie nie tego, co chciałem aby mi pokazano; innymi słowy - ciut 
nie na temat....

> Ja w każdym bądź razie nie zamierzam o tym 
> dyskutować. Ja tylko odpowiedziałem na twoje pytanie o to, gdzie to jest 
> napisane.
No więc właśnie niezupełnie...
Ale, OK - EOT z pozdrowieniem :)

-- 
wloochacz

Dnia 06-10-2009 o 14:03:44 wloochacz <nospam.wloochacz@nospam.dgbit.pl>  
napisał(a):

> yamma pisze:
>> wloochacz wrote:
>>> 3P pisze:
>>
>>>> Ponieważ zalecaną metodą pracy jest tworzenie połączenia na czas
>>>> zapytania i zamykanie po jego wykonaniu
>>> Bzdura.
>>> Kto to zaleca w WindowsForms?
>>  http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
>> "We strongly recommend that you always close the connection when you  
>> are finished using it so that the connection will be returned to the  
>> pool. You can do this using either the Close or Dispose methods of the  
>> Connection object, or by opening all connections inside a using  
>> statement in C#, or a Using statement in Visual Basic. Connections that  
>> are not explicitly closed might not be added or returned to the pool."
> Tu jest napisane, że oni mocno zalecają zamykanie nieużywanego  
> połączenia, żeby wróciło do puli.
> A nie tego, że mocno zalecają używania connection pooling.
>

Widzę, że masz spore problemy z czytaniem ze zrozumieniem. Napisałem ci,  
że się otwiera i zamyka połączenia po ich wykorzystaniu
z czym się nie zgodziłeś. Kolega zacytował, że MS to zaleca, na co ty  
odpowiadasz, że oni nie zalecają connection poolingu
tylko zamykanie połączenia po jego wykorzystaniu (o czym ja napisałem) LOL!

Dnia 06-10-2009 o 11:40:22 wloochacz <nospam.wloochacz@nospam.dgbit.pl>  
napisał(a):

> 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.
Skoro nie da się w .NET to po jakiego grzyba to tutaj piszez? Zauważyłeś  
nazwę grupy?
Poza tym jakbym chciał wykonywać 2 operacje jednocześnie to bym miał 2  
połączenia, albo MARS.

>
> Pisałeś kiedykolwiek w czymś innym niż .NET?
> Tam gdzie nie było poolingu?
Tak, ale nie pisałem aplikacji bazo danowych. A ty chyba w .NET dopiero  
zaczynasz.
>
>> Jednak nie rozumiesz chyba idei connection poolingu.
> Oczywiście.
Dobrze, że tutaj się zgadzamy.
>
>> 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.
>
Już kolega zacytował. To po cholerę się wypowiadasz jak nie masz pojęcia o  
.NET?

>> 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.
A no tak mądralo, że serwer ma ograniczoną liczbę jednoczesnych połączeń.  
Abyś zrozumiał, bo widzę,
że masz spore problemy wyjaśnię ci na takim przykładzie.
Serwer ma ograniczenie do 3 jednoczesnych połączeń. Wg twojego super  
designe'u 3 klientów odpala
aplikację i wykorzystuje te 3 połączenia. Teraz 4 klient chce się połączyć  
i dupa!

W "moim" projekcie każdy z nich bardzo krótko wykorzystuje połączenie.  
Dzięki temu 4 i 40 klient podłącza się
bez problemu.

Teraz zrozumiałeś jak connection pooling przekłada się na więcej klientów?  
Oczywiście bez CP też można
to osiągnąć, ale uzyskiwanie połączeń będzie dłuższe.

>
>> 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.
                          ^^^^^^^^^^^^^
Bez komentarza
>
>> 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...
Już ci napisałem jak to się robi.

>>
>>> Connection pooling daje ci tylko to, że szybciej uzyskujesz połączenia.
>> Niezupełnie szybciej - ...
>> ...- a więc tak, tworzenia połączenia typu pooled jest szybsze.

Bez komentarza

3P pisze:
>>>
>>>> Connection pooling daje ci tylko to, że szybciej uzyskujesz połączenia.
>>> Niezupełnie szybciej - ...
>>> ...- a więc tak, tworzenia połączenia typu pooled jest szybsze.
> 
> Bez komentarza
Zatrudnij się jako spin doctor - nieźle Ci idzie wycinanie kontekstu...

-- 
wloochacz

Dnia 06-10-2009 o 16:03:01 wloochacz <nospam.wloochacz@nospam.dgbit.pl>  
napisał(a):

> 3P pisze:
>>>>
>>>>> Connection pooling daje ci tylko to, że szybciej uzyskujesz  
>>>>> połączenia.
>>>> Niezupełnie szybciej - ...
>>>> ...- a więc tak, tworzenia połączenia typu pooled jest szybsze.
>>  Bez komentarza
> Zatrudnij się jako spin doctor - nieźle Ci idzie wycinanie kontekstu...
>
Wcześniej zacytowałem cały tekst i podkreśliłem, ale się rozjechało.

Dołączę się do tematu bo mnie coś zastanawia...

W dniu 2009-10-06 15:38, 3P pisze:
<....>
>
> W "moim" projekcie każdy z nich bardzo krótko wykorzystuje połączenie.
> Dzięki temu 4 i 40 klient podłącza się
> bez problemu.

Czyli cały Connection Pooling jest obsługiwany po stronie serwera czy 
komponentów dostępowych do bazy?
Po lekturze tego wątku rozjechała mi się nieco definicja CP.

W dniu 2014-06-23 13:46, AbiX pisze:
> Dołączę się do tematu bo mnie coś zastanawia...
>
> W dniu 2009-10-06 15:38, 3P pisze:
> <....>
>>
>> W "moim" projekcie każdy z nich bardzo krótko wykorzystuje połączenie.
>> Dzięki temu 4 i 40 klient podłącza się
>> bez problemu.
>
> Czyli cały Connection Pooling jest obsługiwany po stronie serwera czy
> komponentów dostępowych do bazy?
> Po lekturze tego wątku rozjechała mi się nieco definicja CP.
>

Connection Pooling odbywa się po stronie klienta
czyli w komponentach dostępu do bazy danych.

W swoim kodzie musisz tylko zapewnić, że wywołasz metodę Dispose
na obiekcie SqlConnection natychmiast,
gdy dostaniesz odpowiedź z serwera
i przepiszesz dane do swoich zmiennych.
Dispose woła metodę Close, która to nie zamyka połączenia z bazą,
ale przekazuje je do puli i woła na bazie procedurę składowaną 
sp_reset_connection, która to z kolei zapewnia,
że kolejne odwołanie do bazy danych
będzie dla aplikacji wyglądało jakby zostało wykonane
na nowym połączeniu.

/Robert