Pooling Transactional Objects

Transaktionskomponenten, die im Pool zusammengefasst werden sollen, haben besondere Anforderungen.

Manuelles Auflisten von Ressourcen

Poolfähige Objekte, die an Transaktionen teilnehmen, müssen verwaltete Ressourcen manuell auflisten. Wenn ein Objekt verwaltete Ressourcen zwischen Clients enthält, gibt es keine Möglichkeit für den Ressourcen-Manager, sich automatisch in eine Transaktion einzugeben, wenn das Objekt in einem bestimmten Kontext aktiviert wird.

Das Objekt selbst muss die Logik des Erkennens der Transaktion, des Deaktivierens der automatischen Registrierung des Ressourcen-Managers und des manuellen Eintrags aller darin enthaltenen Ressourcen verarbeiten. Die schritte hierzu sind spezifisch für den ressourcen-manager, den Sie verwenden. Wenn Sie eine manuelle Registrierung durchführen müssen, lesen Sie die Dokumentation für Ihren Ressourcen-Manager.

Wie unten beschrieben, können Objekte mit Transaktionsaffinität gruppiert werden, während eine Transaktion aktiv ist, und mit Transaktionsaffinität aktiviert werden, wenn sie von einem Client aufgerufen werden, der dieser Transaktion zugeordnet ist. Bevor Sie Ressourcen einlisten, sollten Sie zuerst die Transaktionsaffinität überprüfen. Wenn das Objekt aus dem für diese Transaktion spezifischen Pool entnommen wurde, hat es bereits Die Arbeit in dieser Transaktion ausgeführt und seine Ressourcen hinzugefügt.

Deaktivieren der automatischen Einlistung

Die automatische Registrierung sollte deaktiviert werden, nachdem die Ressource abgerufen wurde, normalerweise im Konstruktor des Objekts. Das heißt, Sie deaktivieren die automatische Registrierung und stellen dann eine Verbindung her.

Das Deaktivieren der automatischen Inlistung kann manchmal ein subtiles Verfahren sein, insbesondere bei mehrschichtigen Datenzugriffsanbietern. Die automatische Registrierung wird manchmal mit Verbindungspooling gekoppelt, z. B. mit ODBC, und manchmal nicht, wie bei OLE DB. Möglicherweise müssen Sie sicherstellen, dass die automatische Registrierung auf mehreren Anbieterebenen deaktiviert ist.

Implementieren von IObjectControl

Poolfähige Objekte, die an Transaktionen teilnehmen, müssen den aktuellen Zustand der Ressourcen überwachen, die sie speichern. Wenn das Objekt erkennt, dass es sich in einem nicht wiederverwendbaren Zustand befindet, z. B. bei einer fehlerhaften Verbindung, sollte false für IObjectControl::CanBePooled zurückgegeben werden. Dies führt sowohl dazu, dass das Objekt instance verworfen wird als auch die aktuelle Transaktion zum Scheitern verurteilt wird.

Transaction-Specific Pools

Ein Pool von Objekten ist im Allgemeinen homogen, und jedes poolierte Objekt, das derzeit nicht verwendet wird, ist gut, um an jeden Client zurückzukehren. Die einzige Ausnahme von dieser Regel ist der Fall von Transaktionsobjekten, für die das Objektpooling optimiert ist. Wenn der Client, der ein Objekt anfordert, über eine zugeordnete Transaktion verfügt, überprüft COM+ den Pool nach einem verfügbaren Objekt, das dieser Transaktion bereits zugeordnet ist. Wenn ein Objekt mit Transaktionsaffinität gefunden wird, wird es an den Client zurückgegeben. andernfalls wird ein Objekt aus dem allgemeinen Pool zurückgegeben.

Auf diese Weise werden spezielle Unterpools beibehalten, die Objekte mit Affinität zu einer bestimmten Transaktion enthalten. Wenn die Transaktion commits oder abgebrochen wird, werden diese Objekte ohne Transaktionsaffinität an den allgemeinen Pool zurückgegeben, der von jedem Client verwendet werden kann.

Wenn Ihre Komponente ihre verwalteten Ressourcen manuell in eine Transaktion einlistet, sollte sie zuerst überprüfen, ob sie bereits eingetragen sind. Wenn ja, müssen Sie sich nicht eintragen.

COM+-Objektkonstruktorzeichenfolgen

Steuern von Objektlebensdauer und -zustand

Funktionsweise des Objektpoolings

Verbessern der Leistung mit Objektpooling

Anforderungen für Poolfähige Objekte