Anforderungen für poolfähige Objekte

Poolfähige Objekte müssen bestimmte Anforderungen erfüllen, damit eine einzelne Objektinstanz von mehreren Clients verwendet werden kann.

Zustandslos

Um Sicherheit, Konsistenz und Isolation zu gewährleisten, sollten poolfähige Objekte keinen clientspezifischen Zustand von Client zu Client enthalten. Sie können jeden clientspezifischen Zustand mithilfe von IObjectControlverwalten, eine kontextspezifische Initialisierung mit IObjectControl::Activate durchführen und alle Clientstatus mit IObjectControl::D eactivatebereinigen. Weitere Informationen finden Sie unter Steuern der Objektlebensdauer und des Zustands.

Keine Threadaffinität

Poolfähige Objekte können nicht an einen bestimmten Thread gebunden werden. Andernfalls kann die Leistung möglicherweise unerschwert sein. Aus diesem Grund können poolfähige Objekte nicht für die Ausführung im Apartmentmodell markiert werden. sie müssen im Multithread-Apartment oder im neutralen Apartment ausgeführt werden. Darüber hinaus sollten poolfähige Objekte weder lokalen Threadspeicher verwenden noch den Freethread-Marshaller aggregieren. Weitere Informationen zum Threading in COM+ finden Sie unter COM+-Threadingmodelle.

Hinweis

Microsoft Visual Basic 6.0 und frühere Entwicklungsumgebungen können nur Apartmentmodellkomponenten erstellen. In Visual Basic .NET können Komponenten jedoch in einem Pool zusammengefasst werden.

Aggregierbar

Poolfähige Objekte müssen aggregation unterstützen, d. h., sie müssen die Erstellung durch Aufrufen von CoCreateInstance mit einem pUnkOuter-Argument unterstützen, das nicht NULL ist. Wenn COM+ ein in einem Pool zusammengefasstes Objekt aktiviert, wird ein Aggregat erstellt, um die Lebensdauer des in einem Pool zusammengefassten Objekts zu verwalten und Methoden für IObjectControlaufzurufen. Ausführliche Informationen zum Schreiben von aggregierbaren Objekten finden Sie unter Aggregation.

Transaktionskomponenten

Poolfähige Objekte, die an Transaktionen teilnehmen, müssen verwaltete Ressourcen manuell eintragen. Wenn ihr Objekt eine verwaltete Ressource enthält, z. B. eine Datenbankverbindung, kann der Ressourcen-Manager beim Aktivieren des Objekts im kontextgesteuerten Kontext keine automatische Eintragung in eine Transaktion durchführen, während es in einem Pool zusammengefasst ist. Daher muss das Objekt selbst die Logik der Erkennung der Transaktion verarbeiten, die automatische Eintragung des Ressourcen-Managers deaktivieren und alle darin enthaltenen Ressourcen manuell eintragen. Darüber hinaus sollte ein Transaktionspoolobjekt den aktuellen Zustand seiner Ressourcen in den Parameterwerten von IObjectControl::CanBePooledwiderspiegeln. Weitere Informationen finden Sie unter Pooling Transactional Objects.

Implementieren von IObjectControl zum Verwalten der Objektlebensdauer

Poolfähige Objekte sollten IObjectControlimplementieren, obwohl dies nicht unbedingt erforderlich ist. Transaktionskomponenten, die in einem Pool zusammengefasst sind, müssen jedoch IObjectControl implementieren. Diese Komponenten sollten den Zustand der Ressourcen überwachen, die sie enthalten, und angeben, wann sie nicht wiederverwendet werden können. Wenn IObjectControl::CanBePooled false zurückgibt, wird eine Transaktion untergangen. Weitere Informationen finden Sie unter Steuern der Objektlebensdauer und des Zustands.

Spracheinschränkungen

Komponenten, die mit Microsoft Visual Basic 6.0 und früher entwickelt wurden, können nicht in einem Pool zusammengefasst werden, da diese Komponenten im Apartmentmodell gethreadt werden. In Visual Basic .NET können Komponenten jedoch in einem Pool zusammengefasst werden.

Legacykomponenten

Solange sie nicht transaktional sind und den entsprechenden vorherigen Anforderungen entsprechen, können Komponenten auch dann in einem Pool zusammengefasst werden, wenn sie nicht speziell unter Berücksichtigung der Poolfunktion geschrieben wurden. Es ist nicht erforderlich, IObjectControlzu implementieren. Eine Komponente, die dies nicht tut, nimmt einfach nicht an der Verwaltung ihrer Lebensdauer teil. Wenn IObjectControl::CanBePooled nicht implementiert ist, wird das Objekt weiterhin wiederverwendet, bis der Pool die maximale Größe erreicht.

COM+-Objektkonstruktorzeichenfolgen

Steuern der Lebensdauer und des Zustands von Objekten

Funktionsweise von Objektpooling

Verbessern der Leistung mit Objektpooling

Pooling Transactional Objects