Announcement

**Andreas Kosch** · 24.07.2001, 14:25

Hallo,

mit dem MTS und COM+ sind Singleton-Server nicht m�glich, da jeder Base Client eine eigene Activity erh�lt. Wenn das Singleton-Prinzip beibehalten werden soll, muss das Ganze als normaler COM-Server laufen, der seine eigene ClassFactory implementiert

**Frank Link** · 24.07.2001, 17:24

Hallo,

vielen Dank f�r die Antwort.

Leider nicht sehr befriedigend. Wir sind darauf angewiesen, dass die Objekte sehr stark untereinander referenzierent arbeiten. Das w�rde letztendlich bedeuten, dass wir die Arbeit vollst�ndig �ber die Datenbank abwickeln m�ssen. Bei den kleinen Informationseinheiten mit denen wir es zu tun haben ist dies viel zu langsam. Als Datenbankserver setzen wir Interbase mit IBX ein.

Kurze Programmbeschreibung
Als kleinste Informationseinheit steht bei uns das Wort. Wort referenziert alls S�tze �ber alle Dokumente. Das Wort ist im System genau einmal vorhanden. Nur so sind wr in der Lage unseren Anwendern ein Informationssystem aufzubauen, dass bei einer Suche alle Wortformen und Synonyme ber�cksichtigt. Zus�tzlich bieten wir verschiedene linguistische Auswertungen �ber Begriffzusammenh�nge. Ein Unternehmen kann sich mit diesem System ein Glossar mit der Unternehmensbegriffen aufbauen (Normsprachenansatz). Das Glossar wird f�r die Modellierung von dynamischen (EPK) und statischen Aussagen (UML-ClassDiagramm) verwendet (Modellaussagen). Die Modellaussagen werden zur Generierung von Softwarekomponenten verwendet.

Das als Kurzbeschreibung unserer Anwendung NOAM (Chomsky)

Sehen Sie vielleicht noch eine andere L�sung um eine extrem skalierbare Intra- / Internet taugliche Anwendung zu erstellen?
Wenn es nichts anderes gibt m�ssen wir auf einen althergebrachten HTTP-Server zur�ckgreifen. In einer Three-Tier Architektur mit einem eigenen Objektcache. Eine sehr arbeitsreiche L�sung.

Gruss
Frank Lin

**Andreas Kosch** · 25.07.2001, 08:05

Hallo,

der MTS (COM+) ist immer dann sehr gut, wenn dort zustandslose Objekte ausgef�hrt werden. Unmittelbar nach dem Ende der aufgerufenen Interface-Methode werden diese Objektinstanzen automatisch zerst�rt, um beim n�chsten Aufruf automatisch wieder zum Leben erweckt zu werden (Just-In-Time-Activation). Dies bedeutet jedoch, dass diese Objekte selbst keine Zustandsdaten speichern k�nnen. Es stehen verschiedene Techniken zur Verf�gung, um Zustandsdaten trotzdem zwischenzuspeichern: 
1. Der Client speichert die Zustandsdaten und �bergibt diese bei jedem Methodenaufruf als Parameter. 
2. Die zustandslosen COM+ Objekte verwenden ein gemeinsames Hilfsobjekt, das Daten in globalen Variablen (Modul) speichert. Auch dann, wenn mit aktiviertem JITA auf dieses Hilfsobjekt zugegriffen wird, teilen sich alle Aufrufer die globalen Daten gemeinsam. 
3. Die zustandslosen COM+ Objekte greifen auf den Shared Property Manager zur�ck. 
4. Der Base Client greift auf eine globale Variable des COM+ Objekts zu. 
5. Die zustandslosen COM+ Objekte greifen - falls sie aus einer Active Server Page heraus aufgerufen werden - auf die globalen Application-Variablen von ASP zur�ck.

Wenn man sich die plausibelsten Alternativen anschaut und die m�glichen Implementierungen gegen�berstellt, ergeben sich die folgenden Performance-Ergebnisse:
<pre>
Apartment JITA Synchronisierung Zeit in Ticks f�r 500 Aufrufe
------------------------------------------------------------------
Free Ja Erforderlich 3075
Free Nein Deaktiviert 3015
TNA Ja Erforderlich 1041
TNA Nein Deaktiviert 1032
nur SPM Ja Erforderlich 151
globale Var Ja Erforderlich 80
</pre>
Neben dem Shared Property Manager ist die globale Variable in der DLL (kein zus�tzliches COM+ Hilfsobjekt) ist schnellsten. Allerdings muss man sich dann um die Thread-Abschottung bei den Zugriffen darauf wieder selbst k�mmern

**Frank Link** · 25.07.2001, 10:46

Hallo Herr Kosch,

wenn ich Ihre Tabelle richtig interpretiere, schlagen Sie vor unser Einstiegsobjekt mit globalen Variablen zu versehen. Die Zugriffssteuerung k�nnten wir �ber einen implementierten Mutex entsprechend steuern.

Da alle Schritte, anlegen neuer Objekte, suchen von Objekten �ber deren ID �ber diesen zentralen Punkt geschieht, w�rde dies bedeuten, dass wir nur an dieser Stelle einen theoretischen Engpass h�tten, den wir durch geschickte Implementierung umgehen k�nnten.

Aus meiner Sicht m��ten wir lediglich die schreibenden Zugriffe �ber den Mutex sch�tzen. Alle lesenden Zugriffe (Schleifen etc.) k�nnen wir ohne Mutex erlauben, wenn die Counter vorher in lokalen Variablen abgelegt werden.

Da wir den Client und den Server bereits soweit isoliert von einander betreiben k�nnen, dass der Client nach Abschluss Arbeit, lediglich seine bearbeiteten Daten an den Server �bergibt, m�ssen wir nur daf�r sorgen, dass wir dies asynchron tun k�nnen.

Ich habe Ihnen einen Ausschnitt unserer Thread Implementierung begef�gt. Sie sehen, dass wir an den Worker zwei Interface-Zeiger �bergeben. Bereits bei der Zuweisung der Interface an das eigentliche Worker-Objekt erhalten wir eine Runtime-Exception. Zur Zeit haben wir keine L�sung. Zumal die ganze Sache als reiner DCOM-Server einwandfrei l�uft.

TDocumentThread = class( TThread ) 
private 
FText : String; 
FDocument : INoamMTSDocument; 
FFactory : INoamMTSFactory; 
protected 
procedure Execute; override; 
public 
constructor Create( const Document : INoamMTSDocument; const Factory : INoamMTSFactory; const Value : String ); 
end; 

constructor TDocumentThread.Create( const Document : INoamMTSDocument; const Factory : INoamMTSFactory; const Value : String ); 
begin 
inherited Create( true ); 
FDocument := Document; 
FFactory := Factory; 
FText := Value; 
end;
 
procedure TDocumentThread.Execute; 
var 
FWorkDocument : INoamWorkDocument; 
ThreadNummber : Integer; 
begin 
ThreadNummber := ThreadForm.addThreadMessage( 'Dokument - wird zerlegt.' ); 
try 
CoInitialize( nil ); 
FWorkDocument := CoNoamWorkDocument.Create; 
FWorkDocument.Text := FText; 
FWorkDocument.Factory := FFactory; 
FWorkDocument.Document := FDocument; 
FWorkDocument.work; 
finally 
CoUninitialize; 
ThreadForm.removeThreadMessage( ThreadNummber ); 
end; 
end; 

Gruss
Frank Lin

**Andreas Kosch** · 26.07.2001, 07:40

Hallo,

Delphi stellt mit TMultiReadExclusiveWriteSynchronizer bereits einen Mechanismus bereit, um nur die Schreibzugriffe zu koordinieren.
Das Problem mit der globalen DLL-Variablen liegt nur darin, dass dies ein sehr "fl�chtiger" Speicher ist. Wenn kein Client mit der COM+ Anwendung arbeitet und die Timeout-Zeitspanne f�r das automatische Herunterfahren erreicht wird oder die Anwendung explizit heruntergefahren wird, gehen die Daten verloren. Man ben�tigt also einen Weg, bei Bedarf hier gegenzusteuern.

Generell ist es beim MTS/COM+ keine gute Idee, eigene Threads aus den COM-Objekten heraus abzuspalten. Statt dessen sollte man auf den automatischen Thread-Pool vertrauen und bei Bedarf nur zus�tzliche Objektinstanzen anfordern (die vom MTS/COM+ in einem eigenen Thread ausgef�hrt werden). Die Parallelit�t erreicht man also durch die Implementierung als separate Objekte.

Auf der Client-Seite sind mehrere Threads jedoch kein Problem. Wenn der Thread beim Erzeugen �ber Create bereits "scharfe" Interface-Zeiger erh�lt, ist das in Ihrer Implementierung nur dann ohne spezielle Vorbehandlung legal, wenn alle Objekte im gleichen Apartment laufen (genauer gesagt m�ssen alle als MTA implementiert werden und auch der Aufrufprozess muss ein MTA anmelden). Der �blichere Weg (und f�r die VCL der stabilere Weg) besteht jedoch darin, von STA-Objekten auszugehen und die Interface-Zeiger entsprechend vorzubereiten: 
a) CoMarshalInterThreadInterfaceInStream bereitet im prim�ren Thread den Interface-Zeiger so vor, dass er als Parameter f�r Create (TThread) verwendet werden darf. 
b) CoGetInterfaceAndReleaseStream sorgt in Execute (TThread) daf�r, dass der Marshaler eine legale Br�cke zu dieser Objektinstanz baut

**Frank Link** · 26.07.2001, 10:15

Hallo Herr Koch,

ich habe heute Ihr Buch erhalten, finde ich in diesem entsprechende Hinweise zu diesen Funktionen und ihre Anwendung?

Ich komme jetzt an meine eigenen Wissensgrenzen im Umgang mit COM/COM+ da ich pers�nlich aus der Corba-Ecke komme. Wir haben uns f�r COM+ lediglich aus Lizenzgr�nden entschieden.

K�nnen Sie, mir die Seiten in Ihrem Buch nennen, bzw. die Implementierung die ich im vorhergehenden Kommentar angehangen habe so �ndern, dass es theoretisch funktionieren m��te?

Die Instanz des Threads wird �brigens auf Client-Seite gestartet.

Gruss

Frank Lin

**Andreas Kosch** · 27.07.2001, 08:06

Hallo,

in meinem COM/DCOM/COM+ mit Delphi-Buch sind die folgenden Kapitel relevant: 
- Kapitel 4 Marshaler und Apartments (69 Seiten) 
- Kapitel 15 MTS 
- Kapitel 16 COM+ (baut auf Kapitel 15 auf) 
Auf der CDROM sind mehrere Beispielprojekte, die den Zugriff auf Interface-Zeiger aus separaten Threads heraus demonstrieren. Ich w�rde vor eigenen Versuchen in jedem Fall das Kapitel 4 vollst�ndig lesen

**Frank Link** · 27.07.2001, 08:47

Hallo Herr Kosch,

vielen Dank ersteinmal. Ich melde mich in den n�chsten Tagen.

Gruss und sch�nes Wochenende

Frank Lin

**Frank Link** · 27.07.2001, 16:45

Hallo Herr Kosch,

das Lesen von Kapitel 4 hat ausgereicht, um eine asynchrone Kommunikation mit einem MTS-Objekt aufzubauen. Ich brauchte lediglich den Code f�r den Thread etwas zu �ndern.

procedure TDocumentThread.Execute; 
var 
ThreadNummber : Integer; 
FWorkDocument : INoamWorkDocument; 
begin 
OleCheck( CoInitialize( nil ) ); 
ThreadNummber := ThreadForm.addThreadMessage( 'Dokument - wird zerlegt.' ); 
try 
OleCheck( CoGetInterfaceAndReleaseStream( FStream, IID_INoamWorkDocument, FWorkDocument ) ); 
FWorkDocument.work( ThreadNummber ); 
finally 
CoUninitialize; 
ThreadForm.removeThreadMessage( ThreadNummber ); 
FStream := nil; 
end; 
end; 

Wichtig war vor allem, das alle Zuweisungen an das MTS-Workerobject ausserhalb des Threads erfolgten. 

procedure TDocumentForm.acSendSequenceExecute(Sender: TObject); 
var 
FWorkDocument : INoamWorkDocument; 
Stream : IStream; 
Thread : TDocumentThread; 
begin 
acSendSequence.Enabled := false; 
TEditorDocumentForm(EditorPanel.Form).Editor.SelAt tributes.BkColor := clYellow; 
Text := TEditorDocumentForm(EditorPanel.Form).Editor.SelTe xt; 

FWorkDocument := CoNoamWorkDocument.Create; 
FWorkDocument.Document := FDocument; 
FWorkDocument.Factory := FFactory; 
FWorkDocument.Text := Text; 

OleCheck( CoMarshalInterThreadInterfaceInStream( IID_INoamWorkDocument, FWorkDocument, Stream ) ); 
Thread := TDocumentThread.Create( Stream ); 
Thread.Resume; 
end; 

Seit dem ich den Code so umgestellt habe, l�uft der Aufruf auch dann, wenn ich in der Anwendung mehrere von diesen Threads parallel laufen habe. 

Zusammen, mit der eventfunktionalit�t, die ich mir bei techvanguards.com herutergeladen habe, konnte ich meine gew�nschte Funktionalit�t ziemlich sauber realisieren. 

Wir sind zwar nach wie vor nicht in der Lage den von unsgew�nschten Zentralen ObjectCache aufzubauen, aber die Observer / Obserable Funktionen �ber vertelte Applikationen funktioniert. 

Nochmals vielen Dank f�r die Hilfe. 

Frank Lin

Announcement

MTS, Singleton und Asynchroneaufrufe

MTS, Singleton und Asynchroneaufrufe

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment