Requisiti per gli oggetti poolable
Gli oggetti poolable devono soddisfare determinati requisiti per consentire l'uso di una singola istanza di oggetto da parte di più client.
Senza stato
Per mantenere la sicurezza, la coerenza e l'isolamento, gli oggetti in pool non devono contenere uno stato specifico del client dal client al client. È possibile gestire qualsiasi stato per client usando IObjectControl, eseguendo l'inizializzazione specifica del contesto con IObjectControl::Activate e pulendo qualsiasi stato client con IObjectControl::D eactivate. Per altri dettagli, vedere Controllo della durata e dello stato degli oggetti.
Nessuna affinità thread
Gli oggetti poolable non possono essere associati a un thread specifico; in caso contrario, le prestazioni potrebbero essere potenzialmente disastrose. Per questo motivo, gli oggetti in pool non possono essere contrassegnati per l'esecuzione nel modello apartment; devono essere eseguiti nell'appartamento multithreading o nell'appartamento neutro. Inoltre, gli oggetti poolable non devono usare l'archiviazione locale del thread né devono aggregare il gestore di marshalling a thread libero. Per altri dettagli sul threading in COM+, vedere Modelli di threading COM+.
Nota
Gli ambienti di sviluppo di Microsoft Visual Basic 6.0 e versioni precedenti possono creare solo componenti del modello apartment. Tuttavia, in Visual Basic .NET, i componenti possono essere inseriti in pool.
Aggregabile
Gli oggetti poolable devono supportare l'aggregazione, ovvero devono supportare la creazione richiamando CoCreateInstance con un argomento pUnkOuter diverso da NULL. Quando COM+ attiva un oggetto in pool, crea un'aggregazione per gestire la durata dell'oggetto in pool e per chiamare i metodi in IObjectControl. Per informazioni dettagliate sulla scrittura di oggetti aggregabili, vedere Aggregazione.
Componenti transazionali
Gli oggetti in pool che partecipano alle transazioni devono integrare manualmente le risorse gestite. Mentre è in pool, se l'oggetto contiene una risorsa gestita, ad esempio una connessione al database, non sarà possibile che gestione risorse venga automaticamente inserita in una transazione quando l'oggetto viene attivato in un determinato contesto. Pertanto, l'oggetto stesso deve gestire la logica di rilevamento della transazione, disattivando l'integrazione automatica del gestore risorse e integrando manualmente tutte le risorse contenute. Inoltre, un oggetto in pool transazionale deve riflettere lo stato corrente delle relative risorse nei valori dei parametri di IObjectControl::CanBePooled. Per altri dettagli, vedere Pooling di oggetti transazionali.
Implementare IObjectControl per gestire la durata dell'oggetto
Gli oggetti poolable devono implementare IObjectControl, anche se non è strettamente necessario farlo. I componenti transazionali in pool, tuttavia, devono implementare IObjectControl. Questi componenti devono monitorare lo stato delle risorse che contengono e indicare quando non possono essere riutilizzati; quando IObjectControl::CanBePooled restituisce false, verrà restituita una transazione. Per altri dettagli, vedere Controllo della durata e dello stato degli oggetti.
Restrizioni relative alla lingua
I componenti sviluppati con Microsoft Visual Basic 6.0 e versioni precedenti non possono essere inseriti in pool perché questi componenti verranno threadati in apartment. Tuttavia, in Visual Basic .NET, i componenti possono essere inseriti in pool.
Componenti legacy
Purché non siano transazionali e conformi ai requisiti precedenti appropriati, i componenti possono essere inseriti in pool anche se non sono stati scritti specificamente con la funzionalità di pooling. Non è necessario implementare IObjectControl; un componente che non lo fa semplicemente non parteciperà alla gestione della sua durata. Se IObjectControl::CanBePooled non è implementato, l'oggetto continuerà a essere riutilizzato fino a quando il pool non raggiunge le dimensioni massime.
Argomenti correlati