TRemoteDataModule und Apartment

[Markus Reinisch]

Ich habe zwei Anwendungen!

Die 1. Anwendung ist ein Server mit einen TRemoteDataModule im Single Threading Model(tmSingle).
Im TRemoteDataModule liegen Paradox Tabellen mit Providers.

Die 2. Anwendung ist ein Webanwendung mit einen TWebModule mit ClientDatasets die Daten von der ersten Anwendung über den SocketServer holt. Diese Anwendung kann 5 Internetverbindungen(CacheConnection) gleichzeitig verarbeiten.

Das ganze funktioniert ja gut und ist schon längere Zeit im Betrieb! Aber wenn natürlich mehrere verbindungen zum Server gehen werden Sie serialisiert abgerufen. Das heisst Wartezeit!

Jetzt habe ich den Server auf Apartment(tmApartment) umgestellt und alles so geschützt das es keine Probleme mehr geben sollte mit den Objekten und Variablen und gewisse funktionen mit CriticalSection geschützt.

Das Problem ist das im Server eine Verbindung irgendwann hängenbleibt und alles blockiert.
Es ist nicht nachvollziehbar wann er genau hängenbleibt es ist immer verschieden. z.b.: Ich kann die gleiche funktion 3 mal aufrufen und beim 4 mal hängt er.

Ist es möglich das Delphi hier einen Großen Bug hat. Ich lese nirgends von so einen Problem. Entweder verwendet das Apartment Modell keiner oder ich bin der einzige der damit Probleme hat. Das kann ich mir nicht vorstellen.

Verwende Win2000 Server und Delphi 7.

[Andreas Kosch]

Hallo,

>Ist es möglich das Delphi hier einen Großen Bug hat.

Man kann mit Delphi an dieser Stelle auf die Nase fallen, man muss es aber nicht zwangsläufig. Es gibt in der geschilderten Anwendungsarchitektur gleich mehrere "Sollbruchstellen":

1. Datenzugriff erfolgt über die BDE, wobei mehrere Threads damit arbeiten. Welche Einstellung wurde in der <i>BDE-Verwaltung</i> auf der Registerseite <i>Konfiguration</i> im Zweig <i>System | INIT | MTS Pooling</i> (die Einstellung gilt global für den Rechner für jeden Prozess, also auch für "normale" EXE) vorgenommen?

2. Der Borland Socket Server wurde eingebunden. Mir ist keine Version bekannt, die für den Praxisalltag geeignet ist (völlig triviale Demos ausgenommen). Wenn beide Anwendungen auf verschiedenen Windows 2000 Servern liegen und der Zugriff über das LAN/WAN erfolgt, würde ich zu DCOM wechseln.

3. Das TRemoteDataModul stammt aus dem "alten" VCL-Vererbungszweig und hat somit Wurzeln aus einer Zeit, bei der es noch keine Threads gab (die dann auch potentielle Problemstellen sind, die gerade auf einer Mehrprozessormaschine jederzeit reproduzierbar zu Problemen führen). Im Gegensatz dazu sind alle <b>TComObject</b>-Nachfolger besser geeignet, so dass <b>TMtsAutoObject</b> die erste Wahl an dieser Stelle ist. Innerhalb der Interface-Methode wird dann ein normales Datenmodul (TDataModule) zur Laufzeit als Instanz erzeugt und sofort wieder zerstört. Dank dem JITA-Mechanismus (Just-In-Time-Activation) von COM+ hat das keine Performance-Nachteile - die Leistung steigt im Gegenteil sogar noch gegenüber TRemoteDataModul an.

P.S: Unter Windows 2000 ist <i>tmApartment</i> nur der erste Gang, der für alte VB6-Objekte gedacht ist. Der Normalfall ist das <b>TNA</b> (Thread Neutral Apartment) in einer COM+ Anwendung, erst dort schaltet das Betriebssystem auf den dritten Gang hoch.
&#10