Toon posts:

Disposen in ASP.NET

Pagina: 1
Acties:

Onderwerpen


  • Tarabass
  • Registratie: februari 2008
  • Laatst online: 17-06 23:19
Ik heb een discussie gehad met mijn senior developer, waarin ik aangaf dat ik het raar vond dat in al bestaande code/objecten (gemaakt door een oud-collega) er niets gedisposed wordt. Ik heb het over unmanaged objects zoals sql-objecten etc.. Ik ben gewend deze altijd te disposen (using-statement), maar dit vond mijn senior totaal overbodig. Zijn onderbouwing was dat disposen in ASP.NET geen zin heeft omdat het stateless is en omdat de GC het wel zou opruimen. Daarnaast worden de connections met de SQL-server bewaakt door de application pool dus ik hoefde me nergens druk over te maken.

Maar toch bekruipt mij het gevoel dat dit onzin is. Is het echt onzin om objecten te disposen in ASP.NET? Worden unmanaged objects ook opgeruimd nadat de request is afgerond? En hoe kan ik onderbouwen (test-code, feiten) waarom ik gelijk heb?

Natuurlijk hoop ik dat mijn senior gelijk heeft :P

  • mulder
  • Registratie: augustus 2001
  • Laatst online: 21:27

mulder

ik spuug op het trottoir

Mijn haren staan enigzins overeind :P

oogjes open, snaveltjes dicht


  • Tarabass
  • Registratie: februari 2008
  • Laatst online: 17-06 23:19
mulder schreef op dinsdag 05 oktober 2010 @ 21:24:
Mijn haren staan enigzins overeind :P
Leg uit :)

  • mulder
  • Registratie: augustus 2001
  • Laatst online: 21:27

mulder

ik spuug op het trottoir

Van MSDN:
"The garbage collector in the CLR does not (and cannot) dispose of unmanaged objects, objects that the operating system executes directly, outside the CLR environment. This is because different unmanaged objects must be disposed of in different ways. That information is not directly associated with the unmanaged object; it must be found in the documentation for the object. A class that uses unmanaged objects must dispose of them in its Finalize method."

oogjes open, snaveltjes dicht


  • Tarabass
  • Registratie: februari 2008
  • Laatst online: 17-06 23:19
Dit heb ik inderdaad ook gelezen, net zoals vele blogs waarin disposen wordt aangeraden. Maar hoe heeft dit invloed op de performance van een groot portaal? ik zou het zelf altijd doen (disposen), maar hoe kan ik aantonen dat het beter is en ik toestemming krijg de objecten te verbouwen? :P

  • yade
  • Registratie: mei 2002
  • Laatst online: 17:41
Unmanaged objecten moet je altijd zelf opruimen, maar sql objecten, zijn die unmanaged?

Voor zaken als bijvoorbeeld SqlConnection objecten die de GC wel op zal ruimen is het tóch handig om deze zo snel mogelijk op te ruimen. Connection pooling zorgt er alleen maar voor dat database verbindingen met dure handshakes gewoon open blijven. Als je ervoor kiest om de SqlConnection niet te sluiten of te disposen dan zal er zodra er een nieuwe verbinding nodig is, een nieuwe verbinding worden gemaakt met als gevolg dat in een ongunstige situatie onnodig veel verbindingen naar de database worden gemaakt, en dat alleen maar omdat er nog verbindingen in gebruik zijn door SqlConnection objecten die wachten om eens een keertje opgeruimd te worden door de GC.

Om het kort samen te vatten: Pas als Close of Dispose wordt aangeroepen gaat de in gebruik zijnde verbinding terug naar de connectionpool.

Daarnaast is het gewoon good practice om een class dat IDisposable implementeert zelf op te ruimen.

Verder is ASP.NET niet stateless. In tegendeel.

[Voor 16% gewijzigd door yade op 05-10-2010 22:17]


  • Sebazzz
  • Registratie: september 2006
  • Laatst online: 21:13
Ik vind wel dat je moet disposen, maar lees ook wat er staat:
"The garbage collector in the CLR does not (and cannot) dispose of unmanaged objects, objects that the operating system executes directly, outside the CLR environment. This is because different unmanaged objects must be disposed of in different ways. That information is not directly associated with the unmanaged object; it must be found in the documentation for the object. A class that uses unmanaged objects must dispose of them in its Finalize method."
Indien er met "A class that ..." een IDisposable class bedoelen, betekent dus dat IDisposables hun Dispose methode in de Finalize methode moeten aanroepen of zeg ik nu iets doms?

[Website en online portfolio] [Return: realtime retrospective tool] [PokerTime planning poker]


  • sig69
  • Registratie: mei 2002
  • Laatst online: 00:21
Ja, want de finalizer (of destructor, wat je wil) wordt altijd aangeroepen als een object opgeruimd wordt. Je hebt echter geen enkele controle over wanneer dat gebeurd (kan sowieso wel even duren omdat objecten met een finalizer direct naar de Gen1 heap gaan), daarom vind ik het persoonlijk netter om wel Dispose aan te roepen, dan zijn de unmanaged resources in ieder geval alvast vrijgegeven.

  • Tarabass
  • Registratie: februari 2008
  • Laatst online: 17-06 23:19
Thx, mannen! Het is iets waar ik nooit echt over nadacht, good practice is waarom ik het altijd deed. Maar nu moet ik uitleggen waarom, en zeggen dat het het beste is voor je performance is niet genoeg.

En hoe kan ik dingen testen in code?

  • yade
  • Registratie: mei 2002
  • Laatst online: 17:41
Je zou iets kunnen doen met het openstaande connecties verhaal. Dit kan je zien in de database. Wees creatief. ;)

  • Tarabass
  • Registratie: februari 2008
  • Laatst online: 17-06 23:19
yade schreef op dinsdag 05 oktober 2010 @ 22:30:
Je zou iets kunnen doen met het openstaande connecties verhaal. Dit kan je zien in de database. Wees creatief. ;)
Ik ga er eens goed over nadenken. Als ik wat heb post ik het ook wel hier :)

  • Razr
  • Registratie: september 2005
  • Niet online
Je zou een test kunnen schrijven waarbij je 1000x een for-lus uitvoert waarin een SqlConnection wordt geinstantieerd en gebruikt om een simpele query uit te voeren. Als je de connectie niet sluit en gebruikt maakt van pooling krijg je vanzelf een SqlException dat er geen connecties meer vanuit de pool verkregen kunnen worden.

Als je daaronder nog een for-lus schrijft maar dan met een using statement, of je sluit de connectie expliciet, dan zul je zien dat het daar wel goed gaat. Misschien een opzet voor een paar testen die je kunt aanvoeren als 'bewijs'? :P

  • sig69
  • Registratie: mei 2002
  • Laatst online: 00:21
Dat is in dat geval niet echt een goede test: de senior gaat er vanuit dat de garbage collector alles opruimt omdat alles stateless is. Je zou dus eigenlijk 1000 requests op een pagina die een simpele query uitvoert moeten afschieten.

  • defcon84
  • Registratie: september 2009
  • Laatst online: 07-09 09:08

defcon84

Multipass?

Tarabass schreef op dinsdag 05 oktober 2010 @ 21:19:
Ik heb een discussie gehad met mijn senior developer, waarin ik aangaf dat ik het raar vond dat in al bestaande code/objecten (gemaakt door een oud-collega) er niets gedisposed wordt. Ik heb het over unmanaged objects zoals sql-objecten etc.. Ik ben gewend deze altijd te disposen (using-statement), maar dit vond mijn senior totaal overbodig. Zijn onderbouwing was dat disposen in ASP.NET geen zin heeft omdat het stateless is en omdat de GC het wel zou opruimen. Daarnaast worden de connections met de SQL-server bewaakt door de application pool dus ik hoefde me nergens druk over te maken.

Maar toch bekruipt mij het gevoel dat dit onzin is. Is het echt onzin om objecten te disposen in ASP.NET? Worden unmanaged objects ook opgeruimd nadat de request is afgerond? En hoe kan ik onderbouwen (test-code, feiten) waarom ik gelijk heb?

Natuurlijk hoop ik dat mijn senior gelijk heeft :P
Dit is dus wat men een memory leak noemt.. en dus helemaal fout van je Senior 8)7
Sebazzz schreef op dinsdag 05 oktober 2010 @ 22:11:
[...]
Indien er met "A class that ..." een IDisposable class bedoelen, betekent dus dat IDisposables hun Dispose methode in de Finalize methode moeten aanroepen of zeg ik nu iets doms?
Met "A class" bedoelen ze hier gewoon 'een random class' en die hoeft zelf niet IDisposable te erven. Ze bedoelen dat er in die class objecten zijn die wel IDisposable erven.. en die moet je even manueel disposen als je je class gaat 'stoppen'..
bv:
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class MyClass
{
    System.IO.StreamReader reader;
    private bool isDisposed = false;

    // ctor
    public MyClass() {
        reader = new System.IO.StreamReader();
        isDisposed = false;
    }

    // disposer
    private void Dispose()
    {
        if (isDisposed) return;
        
        reader.Dispose();

        isDisposed = true;
    }

    // dtor
    ~MyClass()
    {
        Dispose();
    }
}

Untappd | "Dogs fucked the pope, no fault of mine." -Hunter S. Thompson


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
Het verhaal dat het stateless is, is sowieso onzin. Ja een HTTP request is stateless, maar de applicatie die in IIS draait zeer zeker niet. Objecten kunnen dus ook langer leven dan de lifetime van een request.

Het is gewoon good practice om voor alle objecten die IDisposable implementeren, en waar jij de owner van bent, Dispose aan te roepen op het moment dat het object end of life is. Op dat moment weet je zeker dat het object de mogelijkheid krijgt om zijn unmanaged resources vrij te geven. Als je dat niet doet betekend het niet zozeer dat je een memmory leak hebt, maar dat je resources voor een te lange periode claimt, en dat kan natuurlijk slecht zijn voor de performance.

Bij de Connections zit het echter nog een stukje complexer. Op het moment dat Dispose aangeroepen word, geeft de Connection zijn resources wel vrij, maar dat hoeft niet perse te betekenen dat de resources helemaal vrij gegeven worden, immers word hij gewoon terug gegeven aan de ConnectionPool. Maar ook dat is iets wat je zo snel mogelijk wil doen, want als je een Connection te lang vast houd, kan het wel zo zijn dat een ander moet wachten totdat hij een Connection krijgt toegewezen, of misschien word er wel een extra connection geopend, en dat kost natuurlijk ook weer resources.
defcon84 schreef op woensdag 06 oktober 2010 @ 09:10:
[...]
Dit is dus wat men een memory leak noemt..
Nee niet zozeer, het feit dat Dispose niet aangeroepen word, zegt niks over het feit of de resouce wel of niet vrij gegeven word, alleen wat over het moment waarop dat gebeurt.
en dus helemaal fout van je Senior 8)7
Dat inderdaad wel.

[Voor 14% gewijzigd door Woy op 06-10-2010 09:17]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Hydra
  • Registratie: september 2000
  • Laatst online: 18:03
Sebazzz schreef op dinsdag 05 oktober 2010 @ 22:11:
Indien er met "A class that ..." een IDisposable class bedoelen, betekent dus dat IDisposables hun Dispose methode in de Finalize methode moeten aanroepen of zeg ik nu iets doms?
Dat ze IDisposable implementeren betekent niet dat ze perse unmanaged resources gebruiken hoor, of dat het falikant misloopt als je ze niet disposed, maar het is m.i. "best practice" om ze netjes te disposen als je er klaar mee bent.

File handles worden bijvoorbeeld netjes vrijgegeven als een File object geGCed wordt, maar dat wil ook niet zeggen dat het niet netter is ze zelf te close()-en :)

Ik vind het verhaal van de "Senior" developer in de TS te triest voor woorden. Zoals iemand anders al aandroeg; een HTTP request mag dan in princiepe stateless zijn, maar je application is dat zeker niet. Unmanaged objecten worden gewoon pas opgeruimd als de applicatie zelf gestopt of gestart wordt.

https://niels.nu


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:35

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Hydra schreef op woensdag 06 oktober 2010 @ 09:41:
Dat ze IDisposable implementeren betekent niet dat ze perse unmanaged resources gebruiken hoor, of dat het falikant misloopt als je ze niet disposed, maar het is m.i. "best practice" om ze netjes te disposen als je er klaar mee bent.
Klopt en helemaal eensch, maar op het moment dat een class IDisposable implementeert en je er geen gebruik van maakt doe je aannames over de interne werking van de class. En dat kan inderdaad best goed gaan. Maar hoewel een class op dit moment misschien nog geen resources gebruikt kan dat in een later stadium/versie natuurlijk wel zo zijn. En daarom is het een best practice te disposen als een class IDisposable implementeert. Je hoort gewoon geen aannames te doen over wat een class intern doet. En assumptions are the mother of all fuckups :P Heerlijk als je die zo nu en dan kunt gebruiken.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • defcon84
  • Registratie: september 2009
  • Laatst online: 07-09 09:08

defcon84

Multipass?

RobIII schreef op woensdag 06 oktober 2010 @ 10:10:
En assumptions are the mother of all fuckups :P
haha idd :D

komt er dus op neer dat je je eigen gewoonte moet aanhouden om Using gebruiken waar mogelijk.. d:)b
en mss eens wisselen van titel met je college :)

Untappd | "Dogs fucked the pope, no fault of mine." -Hunter S. Thompson


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
defcon84 schreef op woensdag 06 oktober 2010 @ 10:55:
[...]
komt er dus op neer dat je je eigen gewoonte moet aanhouden om Using gebruiken waar mogelijk.. d:)b
using waar mogelijk, of als je member variabelen hebt die IDisposable implementeren, zelf ook IDisposable implementeren en in je Dispose methode de Dispose van je members aanroepen.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:35

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Woy schreef op woensdag 06 oktober 2010 @ 11:28:
[...]

using waar mogelijk, of als je member variabelen hebt die IDisposable implementeren, zelf ook IDisposable implementeren en in je Dispose methode de Dispose van je members aanroepen.
Dat, of een try / finally waarin je iig in de finally zorgt voor een dispose.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
RobIII schreef op woensdag 06 oktober 2010 @ 12:14:
[...]

Dat, of een try / finally waarin je iig in de finally zorgt voor een dispose.
Ik kan niet echt een situatie bedenken waar ik try / finally zou verkiezen boven using.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:35

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Woy schreef op woensdag 06 oktober 2010 @ 12:15:
[...]

Ik kan niet echt een situatie bedenken waar ik try / finally zou verkiezen boven using.
Feitelijk is het zelfs hetzelfde:
The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler.
Ik meende alleen dat using een .Net 2.0 feature was en dat je dus <2.0 een try / finally zou moeten gebruiken; maar daar vergiste ik me in :P

[Voor 3% gewijzigd door RobIII op 06-10-2010 12:29]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
RobIII schreef op woensdag 06 oktober 2010 @ 12:28:
[...]
Feitelijk is het zelfs hetzelfde:
Dat snap ik, maar using geeft veel beter aan wat het doel is, en is minder verbose

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:35

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Oh, maar ik ben het ook met je eensch dat je beter een using kunt gebruiken hoor ;)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Tarabass
  • Registratie: februari 2008
  • Laatst online: 17-06 23:19
Bedankt voor de antwoorden, mannen. Hier kan ik wat mee. Het bevestigd mijn gedachten, en ga daar dus niet vanaf wijken. Ik heb mijn senior geconfronteerd met het feit dat ik er van overtuigd ben dat asp.net niet stateless is, waarop ik als antwoord kreeg dat het er aan ligt wat je onder stateless verstaat. Tja. Wel stond hij open voor het overtuigd worden van disposen (eigenlijk al raar dat dat nodig is) dus dat ga ik dan maar proberen. Verder blijf ik gewoon using gebruiken en alles disposen waarvan ik vind dat het gedisposed moet worden. Toch stom dat een senior je zo aan het twijfelen kan zetten, soms moet je toch jezelf volgen. Hopelijk krijg ik de kans om de objecten in de applicatie om te mogen bouwen :)

  • defcon84
  • Registratie: september 2009
  • Laatst online: 07-09 09:08

defcon84

Multipass?

jah.. everybody lies :p veel succes ermee :)

Untappd | "Dogs fucked the pope, no fault of mine." -Hunter S. Thompson

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee