Speicher wird nicht freigegeben

Mein Programm verwendet selbst erstellte DLL’s, welche weitere DLL’s aufrufen.
Bsp: Programm instanziert Session.DLL
Session.DLL instanziert Contact.DLL (ContactManager.cls -> ContactCollection.cls -> Contact.cls)
Contact.cls instanziert System.DLL

Wenn nun mein Programm alle Daten die es braucht gelesen hat, was ca. 70Mb Memory braucht, sollten die DLL’s terminiert werden. Da der Befehl Set Session = nothing etc. nichts bewirkt hat, habe ich in den DLL’s eine Funktion geschrieben, die alle Unterobjekte der DLL terminiert. Das heisst: in der ContactCollection zum Beispiel, loope ich durch die Collection und rufe Collection.remove(xy) auf. Diese Massnahme brachte jedoch keine Linderung meines Memory-Problems. Erst beim Beenden des Programmes wird der Speicher freigegeben. Dies ist jedoch in meiner Client-Server-Architekur nicht möglich.

Hier kommt es stark darauf an, welche (COM-) Properties Deine Klassen besitzen!!!

Zum Beispiel die Property Instancing wirkt sich sehr stark auf die Bereitstellung der Klasse im Speicher aus. Ebenso die MTSTransactionMode (welche nicht nur den Transaction Server betrifft) steuert die Terminierung bzw. Laufzeit. Am besten, Du arbeitest hier mit Transactions, welche Du ganz ganz einfach Aborten kannst.

MTSTransactionMode = 3 (Uses Transaction)
Befehle wie SetComplete, SetAbort und GetObjectContext sind Teile der Transaction-Syntax.

Befasse Dich mal mit Transaktion, deren Isolation und Aggregatzuständen (atomic usw.) - relativ gut beschrieben in der MSDN unter

Platform-SDK
.COM and ActiveX Object Services
…COM
…Automation
…Microsoft Transaction Server

Viel Spaß!

Stefan

ObjectContext.SetComplete

Hi Stefan

Vielen Dank für Deine Antwort.
Was die Properties angeht, so findest Du etwa alles. Vom einfachen String über Late-Binding-Objekte bis hin zu Early-Binding-Objekten. (Ich vermute das Problem bei den Objekten die eine Referenz auf andere DLL’s enthalten.)

Das MTS ein Problem darstellt ist nicht möglich, denn ich arbeite mit Jetstream (Disconnected Recordsets). Aufgrund der Technologie !sollte! nie eine längere Connection vorhanden sein.

cu
Patrik

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]