Serwer Liberty nie obsługuje propagacji transakcji wychodzących ani przychodzących dla
zdalnych interfejsów komponentów EJB. Domyślnie komponenty EJB są zarządzane przez kontener i
używają
atrybutu transakcji Required. Dlatego istniejące
definicje komponentów EJB, które
nie określają żadnych właściwości container-transaction,
są domyślnie skonfigurowane tak, by używały transakcji, mimo że nie są one obsługiwane.
Ta reguła oznacza kod Java odwołujący się do następujących adnotacji EJB, które wskazują na użycie zdalnych interfejsów business lub home:
javax.ejb.Remotejavax.ejb.RemoteHomeTa reguła powoduje oznaczenie także następujących odwołań w pliku ejb-jar.xml:
<remote/><business-remote/>
Specyfikacja komponentów EJB wymaga, aby produkty obsługujące propagację transakcji wychodzących
w dalszym ciągu wysyłały kontekst transakcji o wartości null.
Ten kontekst musi być odrzucany
przez komponenty EJB używające atrybutów
transakcji Required (domyślny), Mandatory lub
Supports . Klient z aktywną transakcją globalną nie może uruchomić komponentu EJB
przy użyciu domyślnych atrybutów transakcji, jeśli klient lub serwer znajduje się na serwerze
Liberty.
Aby umożliwić klientowi uruchamianie komponentu EJB, zmień komponent EJB tak, aby używał
atrybutu transakcji RequiresNew lub NotSupported. Mimo że te atrybuty umożliwią uruchomienie komponentu EJB, działania transakcji wykonane przez komponent EJB nie zostaną
zatwierdzone w ramach transakcji klienta.
Należy zwrócić uwagę, że w przypadku zdalnych interfejsów EJB działających w tej samej maszynie JVM propagacja transakcji jest obsługiwana, jednak można to stwierdzić dopiero po dodatkowej analizie zachowania aplikacji.
Często zdarza się, że komponenty bean EJB 2.x konfigurują w pliku ejb-jar.xml interfejsy zdalne, mimo że nie są one używane.
Interfejsy zdalne są potrzebne tylko wtedy, gdy używany jest kod działający w dwóch różnych maszynach JVM.
W kontekście serwera WebSphere oznacza to działanie na dwóch różnych serwerach aplikacji lub na aplikacji klienckiej i serwerze aplikacji działających w różnych maszynach JVM.
O używaniu zdalnych komponentów bean EJB świadczy też obecność informacji CORBA, takie jak adres URL dostawcy iiop://, w wyszukiwaniu EJB.
Odwołania za pomocą interfejsu zdalnego do komponentów bean EJB działających w tej samej maszynie JVM można zastąpić użyciem interfejsu lokalnego, który będzie działał wydajniej.
Tam, gdzie to możliwe, należy zmienić adnotacje z @Remote na @Local i z @RemoteHome na @LocalHome, a następnie przetestować wszystkie swoje scenariusze działania kodu.
Podobnie należy usunąć z pliku konfiguracyjnego ejb-jar.xml definicje <remote/> i <business-remote/>,
a następnie przetestować wszystkie scenariusze.
Mimo że w tym scenariuszu propagacja transakcji jest obsługiwana, do sprawdzonych procedur należy przejść na użycie interfejsów lokalnych, co przynosi poprawę wydajności i eliminuje wrażenie, że metody można wywoływać zewnętrznie z tej samej maszyny JVM.
W przypadku komponentów bean EJB, które potrzebują dostępu zdalnego, sprawdzoną procedurą jest opakowanie ich w usługę WWW. Strona Dodawanie do komponentu bean EJB adnotacji w celu utworzenia usługi WWW zawiera instrukcję wprowadzania odpowiednich zmian w kodzie za pomocą narzędzi WebSphere Application Server Developer Tools for Eclipse. Po opakowaniu komponentów bean EJB w usługi WWW należy wywoływać usługi WWW tych komponentów za pomocą klienta usług WWW. Po przetestowaniu kodu można usunąć adnotacje lub konfiguracje komponentów EJB odwołujące się do interfejsów zdalnych.
Więcej informacji na tematy pokrewne zawiera strona