Com Object im MTS

[Stefan Glock]

Hallo,

ich möchte im MTS ein Com-Object installieren das die Benutzeranzahl prüft. Jeder Benutzer der sich anmeldet bekommt ein Benutzerobjekt (auch wegen Zugriffsrechten ...) zugewiesen (also mit Transaktion unterstützung um den Status zu behalten). Die Frage ist jetzt was passiert wenn ein Client abschmiert, in diesem Fall würde Set-Complete nie erfolgen! Merkt der MTS das der Client irgendwann nicht mehr aktiv ist oder beendet er die Transaktion generell immer nach einem Timeout Wert?

Bzw. hat jemand eine Idee wie mann sowas mit Com realisieren könnte. Im Prinzip müsste dann für jeden Aufruf zur Fassadenklasse ein gültiges Benutzerobject übergeben werden.

[Andreas Kosch]

Hallo,

über den Eigenschaftsdialog der MTS-Package/COM+ Application kann der Timeout-Wert konfiguriert werden. Sobald dieser Wert bei einer offenen Aktion (d.h. der Aufruf der Interface-Methode kehrt nicht zum Client zurück) erreicht wird, macht der MTS/COM+ automatisch ein Rollback.

Der MTS/COM+ geht davon aus, dass generell mit zustandslosen Objekten gearbeitet wird, die nur für die kurze Zeitdauer des Aufrufs einer Interface-Methode "leben". Man kann diesen Mechanismus zwar deaktivieren (EnableCommit), aber auch kann erhält jeder Client nur seine eigene Objektinstanz, die völlig unabhängig von allen anderen läuft.

Für die o.g. Aufgabe machen zustandsbehaftete Objekte keinen Sinn. Daher würde ich zu den zustandslosen Objekten greifen, so dass jeder Client bei jedem Aufruf einer Interface-Methoden eine "frische" Instanz erhält (Just-In-Time-Activation). Damit die Daten zwischen den Aufrufen nicht verloren gehen, greifen alle Objektinstanzen auf ein gemeinsames Schliessfach im <b>Shared Property Manager</b> des MTS/COM+ zurück

[Stefan Glock]

Ok kann ich so nachvollziehen, aber jetzt die Frage was ist wenn ein Cient sich anmeldet und sein User Object bekommt und er dann irgendwann abschmiert. Bekommt der MTS das irgendwann mit, so daß ich den Zähler (SPM Property) reduzieren kann oder habe ich dazu dann keine Möglichkeit mehr

[Andreas Kosch]

Hallo,

das Prinzip der zustandslosen Objekte bedeutet, dass der MTS noch nicht einmal mitbekommen muss, dass der zweite Aufruf vom gleichen Client kommt. Wenn man so etwas braucht, muss man die Zugriffsrechteprüfung über die ISecurityCallersColl-Methode Get_Item('AccountName') explizit nutzen. Damit ist aber noch nicht das Problem eines abstürzenden Clients vom Tisch. Win32 räumt die offene Verbindung zwar nach dem Timeout automatisch ab, aber das MTS-Objekt wird davon nicht informiert. Man müsste also regelmässig Kontroll-Aufrufe vom Client zum MTS-Objekt vorsehen, so dass der MTS immer dann einen Client aus seinen Daten streichen kann, wenn keine Kontrollaufrufe mehr ankommen. Oder jeder Client implementiert ein eigenes Callback-Objekt, dass zur Kontrolle regelmässig vom MTS aufgerufen werden kann