Kontextaktivierung
In COM+ wird jedes COM-Objekt mit einem zugeordneten Kontext erstellt. Dies bedeutet, dass entweder ein neuer Kontext erstellt und initialisiert werden muss oder ein entsprechender vorhandener Kontext verwendet wird. Dieser Prozess wird als Aktivierungbezeichnet. In COM+ wird ein Objekt entweder in seinem eigenen Kontext oder in der des Erstellers aktiviert (ein Objekt, das angefordert hat, dass das Objekt aktiviert wird, z. B. durch Aufrufen von CoCreateInstance).
Unter bestimmten Umständen, z. B. bei Objektpooling, wird ein Objekt aktiviert, ohne von Grund auf neu erstellt zu werden. In diesem Fall wird eine ausgeführte Instanz in einem Kontext aktiviert. Während der Lebensdauer kann sie in verschiedenen Kontexten wiederholt aktiviert werden.
Der grundlegende Mechanismus ist in beiden Fällen identisch – ein Objekt ist einem Kontext zugeordnet und dieser Kontext wird ordnungsgemäß initialisiert, um die Laufzeitanforderungen des Objekts darzustellen.
Fluss von Kontexteigenschaften
Wenn ein Objekt als Reaktion auf eine Erstellungsanforderung von einem anderen Objekt aktiviert wird, muss COM+ zwischen ihnen vermitteln, um das downstream-Objekt ordnungsgemäß zu aktivieren. COM+ muss den Kontext des Aufrufers mit der Konfiguration der aufgerufenen Komponente vergleichen und dann entscheiden, wo die downstream-Komponente aktiviert werden soll und wie die Kontexteigenschaften initialisiert werden.
Um die Konfiguration der Komponente zu ermitteln, sucht COM+ sie in der COM+-Klassenregistrierungsdatenbank, die für extrem schnelle Laufzeit-Nachschlagevorgänge optimiert ist. (Dies wird durch die Konfiguration einer Komponente bei der Installation in einer COM+-Anwendung bestimmt.) Die Konfiguration der Komponente wird dann anhand des Zustands der Kontexteigenschaften des Aufrufers untersucht.
In einigen Fällen ist die Konfiguration mit dem Kontext des Aufrufers konsistent, und die Komponente kann im Kontext des Aufrufers aktiviert werden. Dies kann nur auftreten, wenn der Kontext des Aufrufers alle Laufzeitanforderungen des neuen Objekts erfüllt.
Wenn die downstream-Komponente nicht innerhalb des Kontexts des Aufrufers aktiviert werden kann, wird sie in einem geeigneten Apartment in ihrem eigenen Kontext aktiviert. In diesem Fall können bestimmte Kontexteigenschaften vom Aufrufer zum Angerufenen fließen. Wenn der Aufrufer beispielsweise einer Transaktion zugeordnet ist und der Angerufene Transaktionen unterstützt, erhält das neue Objekt seinen eigenen Kontext (um in der Transaktion abzustimmen, muss es über ein eigenes einheitliches Flag verfügen) und erbt die Transaktions-ID und Aktivitäts-ID des Anrufers (die sich in derselben Transaktions- und Synchronisierungsdomäne befinden).
Ignorierte Kontexteigenschaften
Je nachdem, wie eine Komponente konfiguriert ist, spielen einige Kontexteigenschaften möglicherweise keine Rolle, um festzustellen, ob sie im Kontext des Erstellers oder im eigenen Kontext aktiviert wird. Die Einstellungen "Transaktionen deaktiviert" und "Synchronisierung deaktiviert" geben beispielsweise an, dass eine Transaktion oder eine Synchronisierungsdomäne vorhanden ist, spielt bei der Aktivierung der Komponente keine Rolle. Diese Eigenschaften werden grundsätzlich ignoriert, wenn der Kontext fließt. Oder wenn eine Komponente nur die Zugriffsüberprüfung auf Prozessebene verwendet, wird die Sicherheitskontexteigenschaft ignoriert – die Sicherheitskonfiguration der Komponente spielt niemals eine Rolle bei der Aktivierung.
Erzwingen der Aktivierung im Kontext des Anrufers
Unter bestimmten Umständen möchten Sie, dass ein Objekt nur im Kontext des Aufrufers aktiviert werden soll , d. h. nie in seinem eigenen Kontext aktiviert werden. Sie können beispielsweise das Verhalten des Objekts steuern, wenn es über eine Kontextgrenze hinweg aufgerufen wird.
Sie können sicherstellen, dass ein Objekt nicht in einem eigenen Kontext aktiviert werden kann, indem Sie die Option Muss im Aufruferkontext aktiviert werden, Option auf der Registerkarte Aktivierung Registerkarte der Komponente Eigenschaften Seite unter Verwendung des Verwaltungstools für Komponentendienste aktiviert werden. (Eine schrittweise Anleitung finden Sie unter Erzwingen der Aktivierung im Kontext des Anrufers.) Wenn Sie diese Option auswählen, kann das Objekt nicht im Kontext des Aufrufers aktiviert werden,"CoCreateInstance" fehlschlägt und CO_E_ATTEMPT_TO_CREATE_OUTSIDE_CLIENT_CONTEXT zurückgibt.
Standardkontext
Standardkontexte sind vorhanden, um nicht konfigurierte Komponenten zu unterstützen, d. h. COM-Komponenten, die nicht in COM+-Anwendungen installiert sind und nicht in der COM+-Klassenregistrierungsdatenbank registriert sind. Wenn nicht konfigurierte Komponenten über ein kompatibles Threadingmodell verfügen, werden sie im Kontext des Aufrufers aktiviert. Andernfalls werden sie in einem Standardkontext in der entsprechenden Wohnung aktiviert. Jedes Apartment verfügt über einen Standardkontext zur Unterstützung von COM-Objekten, die keine COM+-Dienste verwenden.
Hooking Activation
Durch die Implementierung von IObjectControl::Activate und IObjectControl::D eactivatekönnen Sie die Aktivierung und Deaktivierung verbinden, um eine spezielle Initialisierung im neuen Kontext durchzuführen. Diese Methoden werden von COM+ an bestimmten Punkten im Lebenszyklus eines Objekts aufgerufen, wenn das Objekt für die Verwendung von JIT-Aktivierung oder Objektpooling konfiguriert ist. Weitere Informationen finden Sie unter COM+ Just-in-Time-Aktivierung und COM+ Object Pooling.
Verwandte Themen