I en månad brottades företaget med applikationen och fick ideligen fel och det slutade med att deras webblösning stod still väldigt länge då bugg i .net var den troligaste anledningen. Mycket bra gjort Pelle :) Bra gjort! jag tycker det hela låter lite konstigt.Så kan det bli...
I går kväll ringde en tidigare kollega mig i råd på kompetens och efter 15 minuter kunde jag konstatera vart felet låg. http://www2.unt.se/avd/1,1786,MC=1-AV_ID=368475,00.html
Det som syntes var att en mängd nya connections öppnades, närmare bestämt 400 och bara fortsatte till sql-servern dök. När jag tittade på deras kodning så visade det sig att dom hade en facade och både en forms-applikation och webben körde samma anslutningsmetod.
Vid en snabb blick visade det sig att dom cachade mycket data, inga problem. Stängde datasetet efter sig, självklarhet, och att dom hade samma connectionsträng - ett måste för pooling.
Felet här var att dom stängde datasetet men glömde stänga connection också och därmed eskalerade trådarna mot databasen tills det smällde. Så för er alla, bara för ni gör dr.close, missa inte connection.close också - för det görs inte per automatik.
Lita inte på garbage collection där som städar upp. Öppnar ni en connection, se alltid till att stänga den efter er så fort ni kan. Det här gäller samtliga språk.Sv: Så kan det bli...
Mvh Fredrik Normén NSQUARED
http://fredrik.nsquared2.comSv: Så kan det bli...
Själv står man i kö där på uppsalahem, så det var ju bra att du kunde hjälpa dem.Sv: Så kan det bli...
Om poolingen nu fungerade , så måste dom ju bevisligen haft 400 samtidiga användare för att 400 kopplingar skulle skapas , annars skulle kopplingarna återanvännts.
Och OM dom nu har 400 samtidiga användare så kommer dom ju fortfarande få 400 kopplingar (om dom inte kör med com+ och begränsar antalet kopplingar) ...
jag gissar iaf på att poolingen inte fungerar som den ska där..
//Roger