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 aufrechtzuerhalten, sollten poolfähige Objekte keinen clientspezifischen Zustand vom Client bis zum Client enthalten. Sie können jeden clientspezifischen Zustand mithilfe von IObjectControl verwalten, die kontextspezifische Initialisierung mit IObjectControl::Aktivieren und Bereinigen eines beliebigen Clientstatus mit IObjectControl::D eactivate. Weitere Details 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 könnte die Leistung potenziell verheerend sein. Aus diesem Grund können poolfähige Objekte nicht im Apartmentmodell ausgeführt werden; sie müssen in der Multithread-Wohnung oder in der neutralen Wohnung laufen. Darüber hinaus sollten poolfähige Objekte weder den lokalen Threadspeicher verwenden noch den Freithread-Marshaler aggregieren. Weitere Informationen zum Threading in COM+ finden Sie unter COM+-Threadingmodelle.
Hinweis
Die Microsoft Visual Basic 6.0 und frühere Entwicklungsumgebungen können nur Apartmentmodellkomponenten erstellen. In Visual Basic .NET können jedoch Komponenten gruppiert werden.
Aggregierbar
Poolfähige Objekte müssen Aggregation unterstützen– d. h. sie müssen die Erstellung durch Aufrufen von CoCreateInstance mit einem Argument ohne NULL-pUnkOuter unterstützen. Wenn COM+ ein pooliertes Objekt aktiviert, erstellt es ein Aggregat zum Verwalten der Lebensdauer des poolierten Objekts und zum Aufrufen von Methoden auf IObjectControl. Ausführliche Informationen zum Schreiben aggregatierbarer Objekte finden Sie unter Aggregation.
Transaktionskomponenten
Poolfähige Objekte, die an Transaktionen teilnehmen, müssen verwaltete Ressourcen manuell auflisten. Wenn ihr Objekt zwar eine verwaltete Ressource wie eine Datenbankverbindung enthält, gibt es zwar keine Möglichkeit, dass der Ressourcen-Manager automatisch in einer Transaktion auflisten kann, wenn das Objekt im angegebenen Kontext aktiviert wird. Daher muss das Objekt selbst die Logik der Erkennung der Transaktion behandeln, die automatische Listenliste des Ressourcenmanagers deaktivieren und alle darin enthaltenen Ressourcen manuell auflisten. Darüber hinaus sollte ein transaktionspooliertes Objekt den aktuellen Status seiner Ressourcen in den Parameterwerten von IObjectControl::CanBePooled widerspiegeln. Weitere Details finden Sie unter Pooling Transactional Objects.
Implementieren von IObjectControl zum Verwalten der Objektlebensdauer
Poolfähige Objekte sollten IObjectControl implementieren, obwohl dies nicht unbedingt erforderlich ist. Transaktionskomponenten, die pooled sind, müssen jedoch IObjectControl implementieren. Diese Komponenten sollten den Zustand der von ihnen gehaltenen Ressourcen überwachen und angeben, wann sie nicht wiederverwendet werden können; wenn IObjectControl::CanBePooled "false" zurückgibt, wird eine Transaktion rückgängig gemacht. Weitere Details finden Sie unter Steuern der Objektlebensdauer und des Zustands.
Spracheinschränkungen
Komponenten, die mithilfe von Microsoft Visual Basic 6.0 und früheren Versionen entwickelt wurden, können nicht gruppiert werden, da diese Komponenten apartmentmodelliert werden. In Visual Basic .NET können jedoch Komponenten gruppiert werden.
Legacykomponenten
Solange sie nicht transaktionsfrei sind und den entsprechenden vorherigen Anforderungen entsprechen, können Komponenten gruppiert werden, auch wenn sie nicht speziell mit Poolfunktion geschrieben wurden. Es ist nicht erforderlich, IObjectControl zu implementieren; Eine Komponente, die dies nicht tut, wird nicht daran teilnehmen, ihre Lebensdauer zu verwalten. Wenn IObjectControl::CanBePooled nicht implementiert ist, wird das Objekt weiterhin wiederverwendet, bis der Pool die maximale Größe erreicht.
Zugehörige Themen