WebModule & ADOConnection in Service -> Speicherübrelauf

[markusef]

Neuer Stand:

ich werde das ganze Projekt jetzt doch als .dll für einen IIS aufbauen. Bezüglich der ADO/Webmodule/Service-Geschichte gab es einfach keine Fortschritte und auch (aus meiner Sicht) keine Anhaltspunkte mehr um das ganze Zeitnah zu realisieren.

Mit der .dll unter IIS funktioniert das einwandfrei, danke an der Stelle nochmal an naphets, das war ein super Beispiel zum orientieren !
Ist zwar jetzt ein wenig umständlicher zu handhaben, aber es geht zumindest und das auch sehr performant !

Wenn mal wieder Luft ist werde ich natürlich weiter versuchen das ganze als Service zu realisieren (sowas kann man ja nicht auf sich beruhen lassen ).
Falls euch noch was einfallen sollte, ich werde den Thread dennoch regelmäßig besuchen & updates geben wenn ich an der Problematik weiter getüfftelt habe

[markusef]

Also mit der .dll klappt das soweit wunderbar.
Allerdings wächst der Arbeitsspeicher für die w3wp.exe die die isapi dll nutzt pro Anfrage auch ziemlich schnell ins unermessliche. Nachdem ich die Verbindung des Clients beende bleibt die w3wp.exe einfach bei der Größe stehen und es passiert auch nichts weiter.
Irgendwo mache ich demnach etwas falsch, ich weis aber beim besten Willen nicht was.

Muss ich noch dafür sorgen das die WebModule Threads nach abarbeitung beendet werden ? Ich dachte eigentlich das die Threadverwaltung vom IIS Manager übernommen wird

[nahpets]

Das wird jetzt schwierig, da ich mit dem IIS keinerlei Erfahrung habe. Habe meinen eigenen Webserver (mit den Indy-Komponenten) erstellt. Mit dem nutze ich seit Jahren Isapi-Dlls, auch solche, die ADO nutzen. Habe dort bisher keinen Speicherzuwachs feststellen können. Die DLLs sind alle so aufgebaut, wie in meinem Beispiel. Es gibt also nichts zum Aufräumen ...

Frage: Musst Du ADO nutzen?

Hast Du schonmal mit den Zeos-Komponenten gearbeitet?
Dort kann man auch die ADO-Schnittstelle nutzen.
(Zuletzt hier http://www.delphipraxis.net/191453-z...ml#post1359230 behandelt.)

Bleibt mit denen das Problem erhalten? Wenn nein, würde ich es in den ADO-Komponenten suchen und auf Zeos wechseln.

Eine (langsamere) Alternative:

Erstelle bitte eine neue CGI-Anwendung.
Entferne aus dieser das Webmodul.
Füge das Webmodul Deiner ISAPI-Dlls hinzu.
Im Idealfall hast Du nun (ohne weitere Änderungen) eine CGI-Anwendung mit identischem Funktionsumfang.

Kannst Du diese mit dem IIS nutzen?
Ändert sich etwas, außer dem Laufzeitverhalten?

Was ändert sich bei der w3wp.exe und/oder dem IIS noch?
Neben dem Speicherverbrauch, Handles? Threads? Benutzerobjekte?
Gibt es in der DLL eventuell Speicherlöcher?

Liefert Dir der https://www.heise.de/download/produc...explorer-21841 eventuell genauere Informationen.

Könntest Du bitte den aktuellen Quellcode Deiner momentanen Fassung (dpr und pas) hier posten? Eventuell kann man ja was sehen.
Je nach Umfang könnte ich mal schauen, ob ich sie auf eine eigene Datenbank umkonfigurieren kann und dann mal mit meinem Webserver testen.

Sind hier eventuell hilfreiche Informationen zur Problemlösung zu finden?
http://help.sap.com/saphelp_nw73ehp1...a/frameset.htm

Eine weitere Frage, eher mal so in den Raum geworfen, in der Hoffnung, dass irgendwer aus dem Forum sie beantworten kann:

Der Zugriff auf MaxDB von SAP ist per ODBC, JDBC, SQLDBC (http://open-maxdb-group.org/components/interfaces/) möglich. Welche Zugriffsmöglichkeiten gibt es hier bei aktuellen Delphis, ohne über die ADO-Schnittstelle zu gehen? Gibt es sie überhaupt?