[C#] 1 SQL Connectie dmv Application

[Verwijderd]

Hey,

Ik heb een WebApplicatie gemaakt, waarmee ik bij elke verandering aan een database een nieuwe SQLConncetion gebruikte. Nu wilde ik dit terugbrengen, naar 1 connectie. Dit komt, omdat er soms zooo veel connecties worden gebruikt, dat de SQL server ze reject (iets met pooling, wat niet slim is om uit te zetten). De connecties lekken niet, dat is niet het probleem, maar ik wil een algemene overkoepelende connectie hebben die de hele applicatie kan benaderen, omdat de SQL server (niet express edition) de connecties in korte tijd niet aan kan...

Ik heb toen dit stuk code geschreven (omdat ik dacht de Application overal benaderd kon worden):

C#:

//Connectie maken
        Application["SQLConn"] = new System.Data.SqlClient.SqlConnection(ConfigurationSettings.AppSettings["connection_string"]);
        ((System.Data.SqlClient.SqlConnection)Application["SQLConn"]).Open();

Deze code word aangemaakt in de "void Application_Start(object sender, EventArgs e)" functie, in de global file. Elke keer als de applicatie start, word als het goed is Application["SQLConn"] gedeclareerd.

In een class, genaamd page.cs doe ik dan het volgende (in een class dus):

C#:

// Query uitvoeren
                command = new SqlCommand("", ((SqlConnection)Application["SQLConn"]));
                command.CommandText = "Lange query waar niemand iets aan heeft...";
                
                reader = command.ExecuteReader();

Dit levert echter de volgende error op:


Error 2 The name 'Application' does not exist in the current context


Volgensmij kent de class Application niet, omdat hij niet direct deel uit maakt van de application, hij moet telkens met "new" aangemaakt worden. Toch vroeg ik mij af hoe ik zoiets kan doen? Ik kan natuurlijk telkens het object meegeven tijdens het "new" doen (ik weet niet wat de naam hiervoor is..).

Hoe kan ik dus er voor zorgen dat ik 1 connectie heb die de hele webapplicatie kan gebruiken?

Alvast bedankt

[whoami]

Verwijderd schreef op zondag 27 augustus 2006 @ 17:47:
Hey,

Ik heb een WebApplicatie gemaakt, waarmee ik bij elke verandering aan een database een nieuwe SQLConncetion gebruikte. Nu wilde ik dit terugbrengen, naar 1 connectie. Dit komt, omdat er soms zooo veel connecties worden gebruikt, dat de SQL server ze reject (iets met pooling, wat niet slim is om uit te zetten). De connecties lekken niet, dat is niet het probleem

Dit snap ik niet.
Als je connections niet 'lekken', dan ga je toch ook niet 'veel' connecties gaan hebben ?
Zolang jij je connectie iedere keer netjes sluit als je voor een tijd geen DB access meer nodig hebt, dan is er toch niets aan de hand ?
(er wel voor zorgen dat je bij evt exceptions je connectie ook opnieuw sluit natuurlijk).

Ik heb toen dit stuk code geschreven (omdat ik dacht de Application overal benaderd kon worden):

Alles wat in de Application state zit, wordt 'gebruikt' door de volledige applicatie en is dus niet user / sessie - gebonden.
Stel:

code:

object o = Application["bliep"];

Als je nu 2 users die van je web-page gebruik maken, dan gaan zowel user A als user B van hetzelfde object 'bliep' gebruik gaan maken.
Lijkt me niet echt handig in dit geval....

Dit levert echter de volgende error op:


Error 2 The name 'Application' does not exist in the current context

Als je wil dat je class Session & Application State kent, dan moet je die class laten inheriten van HttpContext

[ Voor 8% gewijzigd door whoami op 27-08-2006 18:04 ]

[Verwijderd]

Hmm, okay..

Maar met pooling heb ik gelezen, dat je iets van maximaal 100 connecties tegelijk kan hebben? Maar als mijn applicatie draait (met AJAX) en er gaan een hoop mensen allerlei dingen doen... Dan nog krijg ik errors, terwijl ik echt alles netjes afvang, en connecties overal sluit.... Daarom mijn idee om gewoon 1 connectie te hebben, daar alle SQLCommands aan koppelen en weg het gezeur..

Het gaat er bij mij dus om dat er in 1 seconde 100 connecties aangemaakt (kunnen) worden... Een connectie word namelijk niet geopend en meteen gesloten voordat de volgende word gemaakt, er zit tijd tussen het moment dat de query wordt uitgevoerd...

Het vreemde wat ik vind met pooling, is dat dit helemaal niet zou moeten gebeuren, omdat pooling er voor zou moeten zorgen dat connecties met dezelfde connectie string op 1 hoop worden gegooit..


EDIT:

public class Page : HttpContext geeft:

Error 7 'Page': cannot derive from sealed type 'System.Web.HttpContext'

[ Voor 44% gewijzigd door Verwijderd op 27-08-2006 18:10 ]

[whoami]

Verwijderd schreef op zondag 27 augustus 2006 @ 18:05:
Hmm, okay..

Maar met pooling heb ik gelezen, dat je iets van maximaal 100 connecties tegelijk kan hebben? Maar als mijn applicatie draait (met AJAX) en er gaan een hoop mensen allerlei dingen doen... Dan nog krijg ik errors, terwijl ik echt alles netjes afvang, en connecties overal sluit.... Daarom mijn idee om gewoon 1 connectie te hebben, daar alle SQLCommands aan koppelen en weg het gezeur..

En je denkt dus dat, als je 100 mensen gebruik laat maken van dezelfde connectie, dat het dan goed zal gaan ? Of die nu elk hun eigen object hebben, of elk hetzelfde connection object gebruiken ( ), je blijft 100 connections hebben...

Het gaat er bij mij dus om dat er in 1 seconde 100 connecties aangemaakt (kunnen) worden...

Dan denk ik dat je eerst eens even je architectuur / werkwijze moet herzien...

[Sybr_E-N]

1 connectie kan maar 1 ding tegelijk doen. Als je maar 1 connectie hebt, en meerdere mensen op 1 webstie dan krijg je file vorming. Als 1 iemand een hele tabel aan het uitlezen is, dmv een datareader en een andere wil tegelijk tijd wat updaten dan gaat iemand een mooie SQLException krijgen.

[Verwijderd]

Okay, dat 1 connectie maar 1 ding tegelijk kon doen wist ik niet Had ik eigenlijk eerst moeten proberen / opzoeken...

Maar, zoals ik boven ook ge-edit heb.. waarom werkt het pooling dan niet goed? En voor de architectuur... wat moet je doen als je zeg maar 1000 man hebt, dat tegelijkertijd van je webapplicatie gebruik maken, en daarbij ontzettend veel informatie opgehaald en verstuurt moeten worden naar en van de server? Dan kun je er toch niet omheen om telkens een nieuwe connectie te openen?

En omdat het asynchronious gebeurt, kan ik ook niet 1 connectie per user geven, omdat 1 user meerdere requests tegelijkertijd kan hebben...

[H!GHGuY]

je gebruikt de term pooling behoorlijk veel, maar ik heb de indruk dat je neit echt weet waar de spreekwoordelijke klepel hangt...

Connection pooling kan de overhead wegwerken om telkens een nieuwe connectie op te zetten en af te sluiten wegwerken.
Reken erop dat een TCP-connectie opzetten een 3-way handshake nodig heeft, ze afsluiten is een 2-way operatie. Reken op enkele ms lag en je hebt per connectie toch al redelijk wat vertraging.

Hoe connection pooling grosso modo werkt:
Er is een object dat de pool beheert. Je vraagt aan die pool een connectie op, voert er queries op uit en geeft ze nadien terug.

Wanneer je eenmaal pooling hebt kun je op nog 3 manieren je DB-toegang versnellen:
het gebruik van de queries optimaliseren, de queries zelf optimaliseren en het aantal queries proberen beperken.

[LordLarry]

en cachen zodat je helemaal niet naar de database hoeft natuurlijk

[Verwijderd]

Thanks HighGuy voor de uitleg kzal me daar even wat beter in gaan verdiepen nog

LordLarry schreef op zondag 27 augustus 2006 @ 19:26:
en cachen zodat je helemaal niet naar de database hoeft natuurlijk

Wat heb je dan nog aan de database als je alles cached?


Nog even een vraagje, theoretisch

De SQL queries en connecties gebeuren in een Class... Als ik dan in een WebService, de class gebruik, daarna in een webservice iets return.. de WebFunction dus is afgelopen.. dan wordt de class (en dus ook de SQL connecties die daarbinnen zijn gedeclareerd) weer automatisch gewist? Ik kan er immers toch niet meer bij ?

[ Voor 36% gewijzigd door Verwijderd op 27-08-2006 20:18 ]

[gorgi_19]

Verwijderd schreef op zondag 27 augustus 2006 @ 20:14:
Wat heb je dan nog aan de database als je alles cached?

Niet alles, alleen frequent gebruikte data voor een bepaalde tijd. Een cache van 1 seconde kan bij drukbezochte sites al veel schelen.

Nog even een vraagje, theoretisch

De SQL queries en connecties gebeuren in een Class... Als ik dan in een WebService, de class gebruik, daarna in een webservice iets return.. de WebFunction dus is afgelopen.. dan wordt de class (en dus ook de SQL connecties die daarbinnen zijn gedeclareerd) weer automatisch gewist? Ik kan er immers toch niet meer bij ?

Dat hangt er van hoe je een connectie maakt, hoe je deze gebruikt en of je deze zelf vrijgeeft of niet.

[Woy]

Verwijderd schreef op zondag 27 augustus 2006 @ 20:14:
De SQL queries en connecties gebeuren in een Class... Als ik dan in een WebService, de class gebruik, daarna in een webservice iets return.. de WebFunction dus is afgelopen.. dan wordt de class (en dus ook de SQL connecties die daarbinnen zijn gedeclareerd) weer automatisch gewist? Ik kan er immers toch niet meer bij ?

Ze zullen ooit waarschijnlijk wel vrij gegeven worden door de GC ( en met native resources is dat zelfs nog niet zeker ). Het vervelende is dat je nooit weet wanneer dat gebeurt. En zeker met dingen als connecties wil je dat ze zo snel mogenlijk weer vrij gegeven worden. Connecties kan je dan ook het best op de volgende manier gebruiken

C#:

using( Connection con = new Connection(...) )
{
    ....
    con.Close();
}

Op deze manier weet je zeker dat aan het eind van de using statement je connection weer gedisposed wordt en dus weer terug wordt gegeven aan de connection pool

[Alex]

Hoewel ik natuurlijk weer veel te ver vooruit denk: Enterprise Library met het Data Access Application Block?
Dat neemt je al developer al zoveel 'meuk' uit handen. En het is nog duidelijk gedocumenteerd ook.

[gorgi_19]

Alex de Groot schreef op maandag 28 augustus 2006 @ 23:40:
Hoewel ik natuurlijk weer veel te ver vooruit denk: Enterprise Library met het Data Access Application Block?
Dat neemt je al developer al zoveel 'meuk' uit handen. En het is nog duidelijk gedocumenteerd ook.

Neem dan gelijk een O/R mapper, zoals LLBLGen, ben je er helemaal van af.

[MTWZZ]

Of je gebruikt connection pooling (standaard .Net feature) en implementeerd het Dispose pattern op je class met de connection.
Application blocks en O/R mappers zijn leuk maar ik denk een tikje te enthousiast voor de TS.

[gorgi_19]

MTWZZ schreef op dinsdag 29 augustus 2006 @ 09:46:
Of je gebruikt connection pooling (standaard .Net feature) en implementeerd het Dispose pattern op je class met de connection.

Dan nog weet je niet exact wanneer dispose aangeroepen wordt en hij dus weer teruggegeven wordt aan de connectionpool.

[MTWZZ]

gorgi_19 schreef op dinsdag 29 augustus 2006 @ 09:55:
Dan nog weet je niet exact wanneer dispose aangeroepen wordt en hij dus weer teruggegeven wordt aan de connectionpool.

Mja true, maar toch ik zou het dan iets anders aanpakken dan met de using:

C#:

public sealed class Foo : IDisposable
{
    private SqlConnection m_Connection;
    private bool m_Disposed;

    public Foo() {
        this.m_Connection = new SqlConnection(ConfigurationManager.ConnectionStrings["foo"].ConnectionString);
    }

    ~Foo()
    {
        this.Dispose(false);
    }

    public void Query1() { // doe een query }
    public void Query2() { // doe een query }
    public void Query3() { // doe een query }

    public void Dispose()
    {
        this.Dispose(true);

        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing)
    {
        if(!this.m_Disposed)
        {
            this.m_Disposed = true;

            if(this.m_Connection != null)
            {
                // Is tevens dispose van SqlConnection
                this.m_Connection.Close();
            }
        }
    }
}

Geen idee namelijk of er nog meer queries worden uitgevoerd binnen de life-time van die class.
Je kunt het nog veel spannender maken dmv System.Runtime.ConstrainedExecution.CriticalFinalizerObject wat er voor kan zorgen dat je finalizers _altijd_ aangeroepen worden.

edit:

Hm 2e dispose moet private zijn. Ik heb de class sealed gemaakt ivm GC performance.

[ Voor 9% gewijzigd door MTWZZ op 29-08-2006 10:22 ]

[whoami]

gorgi_19 schreef op dinsdag 29 augustus 2006 @ 09:55:
[...]

Dan nog weet je niet exact wanneer dispose aangeroepen wordt en hij dus weer teruggegeven wordt aan de connectionpool.

Dispose moet je altijd zelf aanroepen.
De Close method van de Connection class doet eigenlijk wat Dispose zou moeten doen (nl de resources vrijgeven, evt naar de connection pool terugplaatsen), maar Close was een betere naam in dit geval.

[Woy]

MTWZZ schreef op dinsdag 29 augustus 2006 @ 10:18:
[...]

Mja true, maar toch ik zou het dan iets anders aanpakken dan met de using:

C#:

public sealed class Foo : IDisposable
{
    private SqlConnection m_Connection;
    private bool m_Disposed;

    public Foo() {
        this.m_Connection = new SqlConnection(ConfigurationManager.ConnectionStrings["foo"].ConnectionString);
    }

    ~Foo()
    {
        this.Dispose(false);
    }

    public void Query1() { // doe een query }
    public void Query2() { // doe een query }
    public void Query3() { // doe een query }

    public void Dispose()
    {
        this.Dispose(true);

        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing)
    {
        if(!this.m_Disposed)
        {
            this.m_Disposed = true;

            if(this.m_Connection != null)
            {
                // Is tevens dispose van SqlConnection
                this.m_Connection.Close();
            }
        }
    }
}

Geen idee namelijk of er nog meer queries worden uitgevoerd binnen de life-time van die class.

edit:

Hm 2e dispose moet private zijn. Ik heb de class sealed gemaakt ivm GC performance.

Mja ik zou toch altijd mijn connection in een Using statement gebruiken. Het ophalen van een connection uit de connection pool is geen "dure" actie. Als je 3 queries uitvoert die met elkaar te maken hebben dan kan je natuurlijk altijd zo iets doen.

C#:

using( Connection con = new Connection() )
{
    Query1( con );
    Query2( con );
    Queyr3( con );
}

Maar als de querys met elkaar te maken hebben zul je waarschijnlijk ook wat met transacties moeten gaan doen.

Zelf zou ik ook kiezen voor een O/R mapper. Het kost initeel wat tijd om het door te krijgen maar als je het eenmaal door hebt bespaart het je een hoop tijd.

[MTWZZ]

rwb schreef op dinsdag 29 augustus 2006 @ 10:25:
[...]

Mja ik zou toch altijd mijn connection in een Using statement gebruiken. Het ophalen van een connection uit de connection pool is geen "dure" actie. Als je 3 queries uitvoert die met elkaar te maken hebben dan kan je natuurlijk altijd zo iets doen.

C#:

using( Connection con = new Connection() )
{
    Query1( con );
    Query2( con );
    Queyr3( con );
}

Dit is IMHO hetzelfde als wat ik gedaan heb alleen haal ik de connectie op via de private member en doet dat using statement hetzelfde als mijn IDisposable/Finalizer.
Wat transacties betreft heb je idd gelijk. Oplossing zou kunnen zijn SqlConnection te deriven en daarbinnen je transacties bij te houden (of je dus al in een transactie zit etc) en die te gebruiken.
Neemt natuurlijk niet weg dat bovenstaande code nog steeds bruikbaar is.
O/R mapper is leuk als je 5+ objecten gaat managen via je app daar onder is het een beetje bloatware IMHO, maar goed ik ken de app van de TS niet dus dat is redelijk ongefundeerd.

[Woy]

MTWZZ schreef op dinsdag 29 augustus 2006 @ 10:34:
[...]

Dit is IMHO hetzelfde als wat ik gedaan heb alleen haal ik de connectie op via de private member en doet dat using statement hetzelfde als mijn IDisposable/Finalizer.
Wat transacties betreft heb je idd gelijk. Oplossing zou kunnen zijn SqlConnection te deriven en daarbinnen je transacties bij te houden (of je dus al in een transactie zit etc) en die te gebruiken.
Neemt natuurlijk niet weg dat bovenstaande code nog steeds bruikbaar is.
O/R mapper is leuk als je 5+ objecten gaat managen via je app daar onder is het een beetje bloatware IMHO, maar goed ik ken de app van de TS niet dus dat is redelijk ongefundeerd.

Het verschil met jou voorbeeld is dat je de tijd waarop gedisposed wordt overlaat aan de gebruiker van je class/GC. Door je connection direct in een using statemt te gebruiken garandeer je dat je na het gebruik van je connection hij direct wordt gedisposed en dus weer terug gegeven wordt aan de connection pool.

Aangezien het geen dure operatie is om een Connection uit de collection pool te verkrijgen denk ik dat je beter je Connection een keer extra kunt disposen dan dat je per ongeluk een connection pas veel later vrij geeft.

[whoami]

Dispose wordt afaik en remember niet door de GC aangeroepen; het is de taak van de programmeur om dat te doen.
Dmv het Dispose pattern kan je er wel voor zorgen dat de Finalizer (die wel door de GC aangeroepen wordt) ook de Dispose aanroept, mocht dat nodig zijn.

Het is idd de bedoeling -zoals rwb zegt- dat je die connectie (en andere unmanaged resources) zo snel mogelijk vrijgeeft, en hier dus niet vertrouwt / wacht op de GC. Beter dus om zelf die Close / Dispose aan te roepen.

[Woy]

whoami schreef op dinsdag 29 augustus 2006 @ 11:19:
Dispose wordt afaik en remember niet door de GC aangeroepen; het is de taak van de programmeur om dat te doen.
Dmv het Dispose pattern kan je er wel voor zorgen dat de Finalizer (die wel door de GC aangeroepen wordt) ook de Dispose aanroept, mocht dat nodig zijn.

Nee idd dat doet hij niet. Ik reageerd ook meer op het voorbeeld van MTWZZ die in zijn Finalizer de Dispose aanroept.

Dispose moet idd of door de gebruiker aangeroepen worden, of het wordt automatisch aangeroepen door het using statement.

[MTWZZ]

whoami schreef op dinsdag 29 augustus 2006 @ 11:19:
Dispose wordt afaik en remember niet door de GC aangeroepen; het is de taak van de programmeur om dat te doen.

Klopt

Dmv het Dispose pattern kan je er wel voor zorgen dat de Finalizer (die wel door de GC aangeroepen wordt) ook de Dispose aanroept, mocht dat nodig zijn.

Inderdaad en dat heb ik ook zo geimplementeerd.

Het is idd de bedoeling -zoals rwb zegt- dat je die connectie (en andere unmanaged resources) zo snel mogelijk vrijgeeft, en hier dus niet vertrouwt / wacht op de GC. Beter dus om zelf die Close / Dispose aan te roepen.

Dat is inderdaad ook zo en zoals rwb hierboven ook opmerkt met het using pattern.

Maar in het geval van Foo als onderdeel van een workflow in de webservice had ik meer zoiets in gedachten:

C#:

public class WS
{
    public WS() { // initialisatie meuk }

    public void Run()
    {
        // Connection wordt hier al geinitialiseerd
        using(Foo f = new Foo())
        {
            f.Query1();  // Select oid
            f.Query2();  // Update
            f.Query3();  // Delete of whatever
        } // En hier gedisposed

        // verdere workflow meuk
    }
}

Op deze manier hou je 1 connection binnen dezelfde class en wordt ie toch zsm vrijgegeven.
Het is, en dat ben ik met jullie eens, dat wanneer er in de Query<n> functies meer processing gebeurt beter om in die functies zelf de connection te releasen.

@whoami hierbeneden:
Ja ik ga er alleen van uit dat de gebruiker van Foo altijd expliciet de Dispose aanroept. Direct door Foo.Dispose of indirect via using. Vergeet iemand dat dan doet de GC het alsnog (en dan weet je idd niet wanneer het gebeurt)

[ Voor 7% gewijzigd door MTWZZ op 29-08-2006 12:44 ]

[whoami]

MTWZZ schreef op dinsdag 29 augustus 2006 @ 11:57:
[...]

Klopt


[...]

Inderdaad en dat heb ik ook zo geimplementeerd.

Alleen weet je nu nooit wanneer die Dispose dus zal aangeroepen worden.

[Verwijderd]

Okay, duidelijke uitleg

Toch ga ik denk ik even voor using op de connectie zelf, omdat me dat op dit moment veel her geprogrammeer scheelt en dan kan ik sneller kijken of het resultaat heeft

Bedankt !

[Woy]

Tja dan geef je de verantwoordelijkheid om je connection te disposen dus over aan de gebruiker van de class. In princiepe kan het wel maar ik zou zelf echter toch eerder kiezen om de verandwoordelijkheid zo dicht mogenlijk bij de owner van de connection te houden. En dus al direct in class Foo de connection te closen. en eventueel een method maken die de 3 query's combineeert