Wymagania dotyczące obiektów, które można połączyć w puli

Obiekty zarządzane przez pulę muszą spełniać określone wymagania, aby umożliwić korzystanie z pojedynczej instancji przez wielu klientów.

Bezpaństwowy

Aby zachować bezpieczeństwo, spójność i izolację, obiekty z możliwością puli nie powinny zawierać stanu specyficznego dla klienta od klienta do klienta. Stanem każdego klienta można zarządzać przy użyciu IObjectControl, wykonując inicjowanie specyficzne dla kontekstu za pomocą IObjectControl::Activate i czyszczenie stanu klienta za pomocą IObjectControl::Deactivate. Aby uzyskać więcej informacji, zobacz Kontrolowanie okresu istnienia obiektu i stanu.

Brak powiązania wątków

Nie można powiązać obiektów zarządzanych przez pulę z określonym wątkiem; w przeciwnym razie wydajność może być potencjalnie katastrofalna. Z tego powodu nie można oznaczyć obiektów z możliwością puli do uruchomienia w modelu mieszkania; muszą one działać w wielowątkowym mieszkaniu lub neutralnym mieszkaniu. Ponadto obiekty z możliwością puli nie powinny używać magazynu lokalnego wątku ani nie powinny agregować marshalera bez wątkowego. Aby uzyskać więcej informacji na temat wątkowania w modelu COM+, zobacz modele wątkowe COM+.

Agregowalny

Obiekty z możliwością puli muszą obsługiwać agregację — czyli muszą obsługiwać tworzenie przez wywołanie CoCreateInstance z argumentem pUnkOuter o wartości innej niż NULL. Gdy COM+ aktywuje obiekt w puli, tworzy agregację, aby zarządzać cyklem życia obiektu w puli i wywoływać metody na IObjectControl. Aby uzyskać szczegółowe informacje na temat tworzenia obiektów możliwych do agregacji, zobacz Agregacja.

Składniki transakcyjne

Obiekty podlegające pulowaniu, które uczestniczą w transakcjach, muszą ręcznie rejestrować zarządzane zasoby. Podczas gdy jest wspólny zasób, jeśli Twój obiekt przechowuje zasób zarządzany, taki jak połączenie z bazą danych, nie będzie możliwości, aby menedżer zasobów automatycznie zarejestrował się w transakcji po aktywacji obiektu w danym kontekście. W związku z tym sam obiekt musi obsługiwać logikę wykrywania transakcji, wyłączając automatyczne rejestrowanie w menedżerze zasobów i ręcznie rejestrować wszystkie przechowywane zasoby. Ponadto obiekt w puli transakcyjnej powinien odzwierciedlać bieżący stan swoich zasobów w wartościach parametrów IObjectControl::CanBePooled. Aby uzyskać więcej informacji, zobacz Pooling Transactional Objects.

Implementowanie kontrolek IObjectControl w celu zarządzania okresem istnienia obiektu

Obiekty pulowane powinny implementować IObjectControl, chociaż nie jest to konieczne. Składniki transakcyjne, które są w puli, muszą implementować IObjectControl. Te składniki powinny monitorować stan przechowywanych zasobów i wskazywać, kiedy nie można ich ponownie użyć; gdy IObjectControl::CanBePooled zwraca wartość false, spowoduje to usunięcie transakcji. Aby uzyskać więcej informacji, zobacz Kontrolowanie okresu istnienia i stanu obiektu.

Ograniczenia języka

Nie można łączyć w puli składników utworzonych w Microsoft Visual Basic 6.0 i wcześniejszych wersjach, ponieważ są one oparte na modelu wątków apartamentowych. Jednak w języku Visual Basic .NET składniki można połączyć w pulę.

Komponenty dziedziczone

Tak długo, jak nie są transakcyjne i są zgodne z odpowiednimi wcześniejszymi wymaganiami, składniki mogą być poolowane, nawet jeśli nie zostały specjalnie napisane z myślą o możliwości poolowania. Nie jest konieczne zaimplementowanie IObjectControl; składnik, który tego nie robi, po prostu nie będzie uczestniczyć w zarządzaniu jego okresem istnienia. Jeśli IObjectControl::CanBePooled nie zostanie zaimplementowany, obiekt będzie nadal ponownie używany, dopóki pula nie osiągnie maksymalnego rozmiaru.

Tematy pokrewne

Ciągi znaków konstruktora obiektów COM+

kontrola cyklu życia obiektu i stanu

jak działa buforowanie obiektów

poprawa wydajności dzięki używaniu puli obiektów

buforowanie obiektów transakcyjnych