Udrzovanie otvoreneho pripojenia – .NET – Fórum – Programujte.com

Ahojte.

Mam aplikaciu, v ktorej taham nejake data zo vzdialenej databazy, nieco rozparsujem a potom to ukladam do databazy. Resp, zaujima  ma, ako spravit to ukladanie do vlastne databazy. Jedna moznost je, ze v jednom kroku natiahnem data, pouzijem nejaku logiku a nasledne ich ulozim. Ta aplikacia ale teraz bezi niekolko minut a myslim, ze v buducnosti tych zaznamov bude este viac, takze po celu dobu by som mal udrzovat otvorene spojenie a to sa mi nezda ako stastne. Mohol by som ho sice po kazdom INSERTE uzavriet a pri dalsom zase otvorit, ale to mi nepride o nic stastnejsie.

Dalsia moznost je, ze najskor naplnim nejaku kolekciu a tu potom nejakou vlastnou metodou ulozim do DB. Tu by to spojenie bolo otvorene podstatne kratsie. Je to ale nejaky a mozno zbytocny kod navyse. Takze, ako by to bolo najvhodnejsie a pripadne preco ? Vdaka.

Nechat otevřené spojení, dokud ho budeš potřebovat, je správné řešení. Není to potřeba nijak obcházet.

Trochu som badal a doslo mi, ze vdaka connection poolingu by nevadilo ani keby som to pripojenie otvaral/zatvaral pri kazdom INSERTe, nie ? Ked uz, takto by sa mi to pacilo viac, lebo by som cele ukladanie mohol napisat do jednej metody a kod by bol trochu prehladnejsi. 

Connection do databáze bys měl zavřít hned, jak ho přestaneš používat, aby se connection, co nejdřív vrátilo do poolu a bylo dostupné ostatním částem aplikace nebo případně i jiným aplikacím a zároveň se uvolnili i zdroje navázané na to připojení.

Pokud používáš SqlConnection, měl bys použít using:

using (SqlConnection connection = <connection code>)
{
  using (SqlCommand command = <command code>)
  {
   // ...
  }
}

using volá Dispose a ten volá Close.

Každá databáze má navíc jen omezený počet připojení a mít neustale otevřené připojení třeba z více počítačů není nic dobrého.

Jestliže třeba v cyklu děláš insert, tak bych to považoval za jedno použití a měl jedno connection na celý cyklus. Pochopitelně také záleží, jaké jsou prodlevy mezi jednotlivými inserty.

Pokud můžeš, snaž se všechny inserty udělat v jednom příkazů a né třeba v cyklu ...

Ano, toto je mi jasne, ale mal som problem aplikovat to na svoj problem. Mne to ukladanie bezi v nejakom foreach a odhadom sa mozno kazde 2-3 sekundy zavola nejaky INSERT. Cele to teda bezi pomerne dlho a preto som nechcel drzat otvorene jedno spojenie celych 10-20 minut. Ak by som data ulozil do kolekcie, ukladanie by prebiehalo ovela rychlejsie, pretoze by sa necakalo na parsovanie a predpokladam, ze spojenie by sa udrzovalo otvorene max 1minutu pocas ktorej by bolo neustale vyuzivane.

Z toho co si pisal som pochopil, ze tie cca 2-3 sekundy je dost dlhy cas na to aby malo zmysel spojenie po kazdom INSERTe ukoncit a spolahnut sa na connection pooling, ze to zmanazuje tak aby to nijak neubral na vykone.

Chapem to spravne ? 

No, ulozit to v jednom prikaze by bol zrejme problem. Neviem si predstavit, ako by som to spravil ... 

Já si myslím, že je to vždycky na individuálním posouzení.

Osobně se většinou snažím zmenšit relaci mezi aplikací a databází na minimum, takže ukládám více záznamů jedním insertem a obdobně se snažím zmenšit i počat vstupů do databáze v rámci čtení - selectu.

Má to však i nevýhody:

• Hůř se to ladí (není jasné, který insert třeba neprošel).
• Záznamy nejsou do databáze uloženy okamžitě, ale až se všemi ostatními. Tady záleží na charakteru aplikace, jestli to vadí nebo ne ...
• Záznamy si před insertem ukládáš v paměti, takže ti roste paměťová náročnost aplikace. Dle mé zkušenosti ve většině případů, je ale nejchoulostivějším zdrojen právě databáze, a proto se snažíš šetřit právě jí. Kdybys měl ukládat třeba milion záznamů, tak si myslím, že ani jedno z těchto dvou krajních řešení (1 insert nebo milion insertů) by nebylo nejsprávnější a chtělo by to nějaký kompromis, třeba ukládání po stovkách.

Co se snažím říct je to, že se na tvoji otázku nedá obecně odpovědět a záleží na povaze aplikace. Ve většině případů platí to, že by connection mělo být otevřeno nejkratší možnou dobu a komunikace s ní, co nejmenší.