Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3)
Z Jacek Laskowski - Wiki Projektanta Java EE
Niedawno dostałem do skrzynki takie pytanie:
(...)Głównie nurtuje mnie "jak długo" po otrzymaniu referencji do ejb mogę go używać (kontener może go przecież spasywować/usunąć albo *** wie, co jeszcze zrobić) - mogę z niego korzystać dowolnie długo/pobierać od nowa co wywołanie metody biznesowej czy jeszcze inaczej?
Początkowo miałem po prostu odpowiedzieć i zapomnieć o temacie. Zdalna referencja jest jedynie pośrednikiem (ang. proxy) między kodem klienta a serwerem i tak na prawdę odpowiada jedynie za komunikację z serwerem bez utrzymywania jakiegokolwiek stanu komponentu EJB. Mimo jasnej dla mnie odpowiedzi, postanowiłem sprawdzić ją w trakcie niewielkiego eksperymentu, który miał mi nie tylko zweryfikować samą odpowiedź, ale również dać nową na pytanie, ile czasu potrzeba na zestawienie środowiska do jego przeprowadzenia. Do dyspozycji miałem linię poleceń lub IDE. Z IDE jest o tyle problem, że trudno wybrać to jedyne (w przypadku projektów Java EE wskazywałbym na NetBeans IDE), więc pozostałem przy linii poleceń. Tak się bawiłem, że skończyło się na nowym artykule.
Skorzystamy z Apache Maven 2.2.1 oraz serwera aplikacyjnego GlassFish v3 b66, aby stworzyć i uruchomić bezstanowe ziarno sesyjne EJB 3.0. Artykuł bazuje na poprzednich, podobnych doświadczeniach, które zostały spisane w Tworzenie aplikacji EJB 3.0 z GlassFish v2, Apache Maven 2 i NetBeans IDE 6.0 oraz Tworzenie aplikacji Java EE 5 z Apache Maven 2 i Glassfish.
Pytania, na które spróbujemy odpowiedzieć to: Jak długo referencja EJB będzie aktywna? oraz Czy potrzebne są jakiekolwiek specjalne kroki, aby zagwarantować jej poprawność?
Zgodnie z dokumentacją GlassFish v3 - Accessing EJB Components in a Remote Enterprise Server:
Objects stored in the interoperable naming context and component-specific (java:comp/env) naming contexts are transient. On each server startup or application reloading, all relevant objects are re-bound to the namespace.
Czytam to jako zapewnienie, że restarty GlassFisha nie wpływają w żaden sposób na poprawność referencji i bez względu na stabilność serwera (jeśli tylko w danej chwili działa) wykonanie metody biznesowej jest możliwe. W naszym przypadku z bezstanowym komponentem EJB sprawa jest wyjątkowo prosta, bo ponowne przyłączenie ziarna EJB do JNDI nie zmienia semantyki uruchomienia go. W końcu jest bezstanowy i takie zatrzymanie i uruchomienie serwera jest idealnym testem, czy faktycznie kod aplikacji nie zakłada inaczej.
Plan działania:
- Zestawienie projektu wielomodułowego ejb3-zdalnyklient-glassfish3 z pomocą Mavena.
- Utworzenie komponentu EJB ejb3 z interfejsem zdalnym pl.jaceklaskowski.javaee.WyswietlanieKomunikatow z pojedynczą metodą void wyswietl(String).
- Utworzenie zdalnego klienta WyswietlanieKomunikatowKlientTest w roli testu integracyjnego (powód wyjaśnię poniżej), który pobiera zdalną referencję komponentu EJB i trzyma ją zasypiając co jakiś czas (dając tym samym możliwość wykonywania zatrzymania/uruchomienia na serwerze aplikacyjnym).
- Uruchamienie serwera GlassFish v3 z komponentem EJB oraz zdalnego klienta, po czym nastąpi seria zatrzymań/uruchomień serwera.
Wykorzystane oprogramowanie:
Kompletny projekt jest dostępny do pobrania jako ejb3-zdalnyklient-glassfish3.zip.
Pomysły na usprawnienie artykułu mile widziane, szczególnie te, które zmniejszą ilość czasu na zestawienie kompletnego środowiska do przeprowadzenia eksperymentu. W tekście można znaleźć kilka adnotacji TODO, które oznaczają miejsca potrzebujące opieki i udoskonalenia. Chętny/-a? Napisz do mnie na priv.
Spis treści |
Zestawienie projektu wielomodułowego - ejb3-zdalnyklient-glassfish3
Sprawdzenie wersji oprogramowania i do dzieła.
jlaskowski@work /cygdrive/c/projs/sandbox $ mvn -v Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_14 Java home: c:\apps\java6\jre Default locale: en_PL, platform encoding: Cp1250 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Stworzenie projektu głównego typu pom
Zaczynamy od stworzenia projektu głównego (typu pom w nomenklaturze mavenowej). Posłużymy się wtyczką archetype i jej poleceniem generate z opcją -B (w trybie wsadowym). Pewnie jest wiele sposobów na stworzenie struktury projektowej z linii poleceń, ale ta wydaje się najmniej wymagająca.
jlaskowski@work /cygdrive/c/projs/sandbox $ mvn archetype:generate -B \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DgroupId=pl.jaceklaskowski.javaee \ -DartifactId=ejb3-zdalnyklient-glassfish3 \ -Dversion=1.0
Przechodzimy do katalogu projektu - ejb3-zdalnyklient-glassfish3 - i odtąd wszystkie polecenia wykonywane będą z jego poziomu.
jlaskowski@work /cygdrive/c/projs/sandbox $ cd ejb3-zdalnyklient-glassfish3/
Domyślnie tworzonym projektem jest projekt typu jar (patrz packaging w pom.xml), więc pierwszym krokiem jest jego zamiana na pom. Skoro nasz projekt będzie korzystał z funkcjonalności zarezerwowanych dla Java SE 5 (adnotacje) konieczne jest podniesienie domyślnej wersji Javy do wersji 1.5 (jako konfiguracja wtyczki maven-compiler-plugin).
Cały plik pom.xml wygląda następująco:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>pl.jaceklaskowski.javaee</groupId>
<artifactId>ejb3-zdalnyklient-glassfish3</artifactId>
<packaging>pom</packaging>
<version>1.0</version>
<name>ejb3-zdalnyklient-glassfish3</name>
<url>http://www.JacekLaskowski.pl</url>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Warto również skasować katalog src, z którego nie bedziemy w ogóle korzystać.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ rm -rf src
Stworzenie podprojektu dla komponentu EJB - ejb3
Podobnie jak to miało miejsce w przypadku zestawienia projektu głównego, wykonujemy polecenie mvn archetype:generate z odpowiednimi opcjami.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ mvn archetype:generate -B \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DgroupId=pl.jaceklaskowski.javaee \ -DartifactId=ejb3 \ -Dversion=1.0
Zmieniam pom.xml podprojektu (plik ejb3/pom.xml) tak, aby packaging był ejb, który informuje Mavena, że to jest projekt EJB. Dodatkowo konieczne jest wskazanie wersji EJB przez konfigurację wtyczki maven-ejb-plugin i dodanie zależności z adotacjami EJB w sekcji dependencies.
Cały plik ejb3/pom.xml prezentuje się następująco:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" >
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>ejb3-zdalnyklient-glassfish3</artifactId>
<groupId>pl.jaceklaskowski.javaee</groupId>
<version>1.0</version>
</parent>
<groupId>pl.jaceklaskowski.javaee</groupId>
<artifactId>ejb3</artifactId>
<packaging>ejb</packaging>
<version>1.0</version>
<name>ejb3</name>
<url>http://www.JacekLaskowski.pl</url>
<dependencies>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-ejb_3.0_spec</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<ejbVersion>3.0</ejbVersion>
</configuration>
</plugin>
</plugins>
</build>
</project>
Kasujemy również domyślnie tworzone pliki App.java oraz AppTest.java.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ find ejb3 -name App*.java | xargs rm
Stworzenie podprojektu dla zdalnego klienta - klient
Kolejny raz korzystamy z mvn archetype:generate z właściwymi dla podprojektu klienta opcjami.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ mvn archetype:generate -B \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DgroupId=pl.jaceklaskowski.javaee \ -DartifactId=klient \ -Dversion=1.0
Rozpoczynamy od porządków w nowozałożonej strukturze projektowej - kasujemy katalog klient/src/main/java/pl oraz klasę klient/src/test/java/pl/jaceklaskowski/javaee/AppTest.java. Nie będą potrzebne, a na ich miejsce pojawi się niebawem nowa klasa testowa.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ rm -rf klient/src/main/java/pl klient/src/test/java/pl/jaceklaskowski/javaee/AppTest.java
Wprowadzamy zmiany w klient/pom.xml tak, aby zawierał konieczne zależności oraz możliwość uruchomienia testu integracyjnego WyswietlanieKomunikatowKlientTest przy odpowiednim wywołaniu Mavena:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" >
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>ejb3-zdalnyklient-glassfish3</artifactId>
<groupId>pl.jaceklaskowski.javaee</groupId>
<version>1.0</version>
</parent>
<groupId>pl.jaceklaskowski.javaee</groupId>
<artifactId>klient</artifactId>
<version>1.0</version>
<name>klient</name>
<url>http://www.JacekLaskowski.pl</url>
<properties>
<glassfish.home>c:/apps/glassfishv3/glassfish</glassfish.home>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>ejb3</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>glassfish</groupId>
<artifactId>appserv-rt.jar</artifactId>
<version>LATEST</version>
<scope>system</scope>
<systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath>
</dependency>
<dependency>
<groupId>glassfish</groupId>
<artifactId>javaee.jar</artifactId>
<version>LATEST</version>
<scope>system</scope>
<systemPath>${glassfish.home}/lib/javaee.jar</systemPath>
</dependency>
<dependency>
<groupId>glassfish</groupId>
<artifactId>jndi-properties.jar</artifactId>
<version>LATEST</version>
<scope>system</scope>
<systemPath>${glassfish.home}/lib/jndi-properties.jar</systemPath>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<includes>
<include>**/WyswietlanieKomunikatowKlientTest.java</include>
</includes>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<excludes>
<exclude>**/WyswietlanieKomunikatowKlientTest.java</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Wypełnianie projektu kodem - programowanie aplikacji
Stworzenie struktury projektowej to pierwszy krok w przeprowadzeniu naszego doświadczenia. Kolejny to właściwe programowanie (zamiast dotychczasowego metaprogramowania, tj. konfiguracji).
Utworzenie bezstanowego ziarna sesyjnego EJB - WyswietlanieKomunikatow
W ramach projektu ejb3 tworzymy interfejs zdalny pl.jaceklaskowski.javaee.WyswietlanieKomunikatow (w pliku ejb3/src/main/java/pl/jaceklaskowski/javaee/WyswietlanieKomunikatow.java).
package pl.jaceklaskowski.javaee;
import javax.ejb.Remote;
@Remote
public interface WyswietlanieKomunikatow {
void wyswietl(String komunikat);
}
Następnie, jak to się szumnie nazywa, realizujemy kontrakt klasą pl.jaceklaskowski.javaee.impl.DomyslneWyswietlanieKomunikatow (w pliku ejb3/src/main/java/pl/jaceklaskowski/javaee/impl/DomyslneWyswietlanieKomunikatow.java). Wcześniej musimy utworzyć katalog ejb3/src/main/java/pl/jaceklaskowski/javaee/impl, np. poleceniem mkdir (w końcu mieliśmy przeprowadzić doświadczenie z linii poleceń).
package pl.jaceklaskowski.javaee.impl;
import java.util.logging.Logger;
import javax.ejb.Stateless;
import pl.jaceklaskowski.javaee.WyswietlanieKomunikatow;
@Stateless(mappedName = "WyswietlanieKomunikatow")
public class DomyslneWyswietlanieKomunikatow implements WyswietlanieKomunikatow {
Logger logger = Logger.getLogger(getClass().toString());
public void wyswietl(String komunikat) {
logger.info(komunikat);
}
}
Dla niecierpliwych i tych potrzebujących zapewnienia, że dotychczasowa praca ma już swój wymierny efekt, zbudujmy projekt (a tym samym i właśnie stworzony komponent EJB) poleceniem mvn install. Uważajmy na katalog, gdzie wykonujemy polecenia mvn - najlepiej, aby to był katalog główny projektu.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ mvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ejb3-zdalnyklient-glassfish3 [INFO] ejb3 [INFO] klient ... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] ------------------------------------------------------------------------ [INFO] ejb3-zdalnyklient-glassfish3 .......................... SUCCESS [3.813s] [INFO] ejb3 .................................................. SUCCESS [1.953s] [INFO] klient ................................................ SUCCESS [1.391s] [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------
Utworzenie klienta zdalnego - WyswietlanieKomunikatowKlientTest
Tworzymy klasę pl.jaceklaskowski.javaee.WyswietlanieKomunikatowKlientTest (w klient/src/test/java/pl/jaceklaskowski/javaee/WyswietlanieKomunikatowKlientTest.java):
package pl.jaceklaskowski.javaee;
import javax.naming.Context;
import javax.naming.InitialContext;
import org.junit.Test;
public class WyswietlanieKomunikatowKlientTest {
@Test
public void testZdalnyKlient() throws Exception {
Context ctx = new InitialContext();
System.out.println("+++ Kontekst JNDI utworzony");
WyswietlanieKomunikatow wyswietlanie = (WyswietlanieKomunikatow) ctx.lookup("WyswietlanieKomunikatow");
System.out.println("+++ Pobranie zdalnej referencji wykonane poprawnie");
for (int i = 0; i < 20; i++) {
String iteracja = "iteracja " + (i + 1);
System.out.println(iteracja);
try {
wyswietlanie.wyswietl("+++ Witaj brachu! [" + iteracja + "]");
} catch (Exception e) {
System.out.println("--- Przechwycono wyjatek: " + e.getLocalizedMessage());
}
Thread.sleep(1000 * 2);
}
}
}
Implementacja klasy jest wyjątkowo prosta i pomijając wyświetlanie komunikatów oraz obsługę błędów w bloku try/catch nie ma tam wiele. Całość konfiguracji JNDI i nawiązania komunikacji z GlassFish obsługują biblioteki pomocnicze zadeklarowane jako dependencies w pom.xml.
Wykonujemy mvn clean install, aby przekonać się, że wszystko jest w należytym porządku, gotowe do finalnego uruchomienia.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ mvn clean install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] ejb3-zdalnyklient-glassfish3 [INFO] ejb3 [INFO] klient ... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] ------------------------------------------------------------------------ [INFO] ejb3-zdalnyklient-glassfish3 .......................... SUCCESS [1.813s] [INFO] ejb3 .................................................. SUCCESS [1.281s] [INFO] klient ................................................ SUCCESS [2.578s] [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------
Uruchomienie środowiska - Uwaga! Doświadczenie w toku
W tej chwili powinniśmy mieć wszystkie konieczne składowe do rozpoczęcia doświadczenia - produkt projektu ejb3 na serwerze GlassFish oraz produkt projektu klient jako test integracyjny. Zaczynamy!
Wdrożenie paczki EJB ejb3-1.0.jar na serwer GlassFish
Rozpoczynamy końcowe odliczanie od wdrożenia pliku jar z komponentem EJB z projektu ejb3 (w katalogu ejb3/target/ejb3-1.0.jar).
W nowym okienku linii poleceń sprawdzamy wersję GlassFish i zaczynamy zabawę.
jlaskowski@work /cygdrive/c/apps/glassfishv3 $ ./bin/asadmin version Version string could not be obtained from Server [localhost:4848] for some reason. (Turn debugging on e.g. by setting AS_DEBUG=true in your environment, to see the details). Using locally retrieved version string from version class. Version = GlassFish v3.0-b66 (build 66) Command version executed successfully.
Uruchamiamy serwer GlassFish poleceniem asadmin start-domain (TODO: tutaj widziałbym usprawnienie w postaci automatycznego uruchamiania GF podczas uruchomienia testów).
jlaskowski@work /cygdrive/c/apps/glassfishv3 $ ./bin/asadmin start-domain Waiting for DAS to start. ....................................... Started domain: domain1 Domain location: C:\apps\glassfishv3\glassfish\domains\domain1 Log file: C:\apps\glassfishv3\glassfish\domains\domain1\logs\server.log Admin port for the domain: 4848 Command start-domain executed successfully.
Wdrożenie paczki EJB to wykonanie polecenia asadmin.bat deploy (TODO: pomoc przy stworzeniu automatu do wdrożenia paczki na GF mile widziana). Polecenie wykonujemy w oknie linii poleceń z naszym projektem.
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3 $ c\:/apps/glassfishv3/bin/asadmin.bat deploy ejb3/target/ejb3-1.0.jar Command deploy executed successfully.
Uruchomienie zdalnego klienta EJB3
Wcześniej uruchomiliśmy serwer GlassFish, a więc teraz możemy uruchomić klienta. Warto w tym czasie obserwować dziennik serwera glassfish/domains/domain1/logs/server.log, w którym pojawią się komunikaty z wywołaniami zdalnej metody EJB.
Uruchamiamy polecenie mvn surefire:test, które wywoła wtyczkę maven-surefire-plugin odpowiedzialną za uruchamianie testów w Maven, która z kolei, zgodnie z konfiguracją w pom.xml, uruchomi test integracyjny WyswietlanieKomunikatowKlientTest. Stworzenie właściwej ścieżki klas (CLASSPATH) do wykonania klienta było powodem oparcia wykonania klienta z poziomu Mavena jako klasy testowej, gdzie niezbędne zależności będą rozwiązane przez niego zdejmując z nas obowiązek dbania o nie (poza samym dbaniem o pom.xml).
jlaskowski@work /cygdrive/c/projs/sandbox/ejb3-zdalnyklient-glassfish3/klient
$ mvn surefire:test
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building klient
[INFO] task-segment: [surefire:test]
[INFO] ------------------------------------------------------------------------
[INFO] [surefire:test {execution: default-cli}]
[INFO] Surefire report directory: c:\projs\sandbox\ejb3-zdalnyklient-glassfish3\klient\target\surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running pl.jaceklaskowski.javaee.WyswietlanieKomunikatowKlientTest
+++ Kontekst JNDI utworzony
2009-10-05 21:55:59 com.sun.enterprise.transaction.JavaEETransactionManagerSimplified initDelegates
INFO: Using com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate as the delegate
+++ Pobranie zdalnej referencji wykonane poprawnie
iteracja 1
Pierwsza iteracja i w dziennikach GlassFisha widać komunikat:
[#|2009-10-05T21:56:01.046+0200|INFO|glassfish|class pl.jaceklaskowski.javaee.impl.DomyslneWyswietlanieKomunikatow| _ThreadID=34;_ThreadName=Thread-3;|+++ Witaj brachu! [iteracja 1]|#]
Wyłączamy jedynie serwer GlassFish poleceniem asadmin stop-domain i obserwujemy klienta.
jlaskowski@work /cygdrive/c/apps/glassfishv3 $ ./bin/asadmin stop-domain Waiting for the domain to stop ............. Command stop-domain executed successfully.
W tym samym momencie, kiedy serwer się zatrzyma kolejna iteracja zostanie również wstrzymana. Taki stan będziemy obserwować dopóki, dopóty serwer GlassFish ponownie się podniesie. Uruchamiamy ponownie GlassFisha poleceniem asadmin start-domain i dopiero co wstrzymana iteracja wznowi swoją pracę.
Czasami może pojawić się wyjątek po stronie klienta, który informuje nas o braku połączenia z serwerem GlassFish:
--- Przechwycono wyjatek: java.rmi.MarshalException: CORBA COMM_FAILURE 1398079689 No; nested exception is:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
Podsumowanie
Zdalna referencja ziarna EJB jest jedynie pośrednikiem (ang. proxy) między kodem klienta a serwerem i tak na prawdę odpowiada jedynie za komunikację z serwerem bez utrzymywania jakiegokolwiek stanu komponentu EJB.
Zgodnie z dokumentacją GlassFish v3 - Accessing EJB Components in a Remote Enterprise Server:
Objects stored in the interoperable naming context and component-specific (java:comp/env) naming contexts are transient. On each server startup or application reloading, all relevant objects are re-bound to the namespace.
Przeprowadzony test udowodnił tezę, że GlassFish v3 b66 utrzymuje poprawność zdalnej referencji EJB bez względu na dostępność serwera i nie jest konieczne wykonywanie jakichkolwiek specjalnych kroków, aby z niej korzystać. Oczywiście w przypadku niedostępności serwera (serwer zatrzymany, brak połączenia sieciowego) pojawi się wyjątek
java.rmi.MarshalException: CORBA COMM_FAILURE 1398079689 No; nested exception is:
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
a więc może być wymagana obsługa wyjątku niekontrolowanego java.rmi.MarshalException, co nie implikuje konieczności ponownego tworzenia kontekstu JNDI i pobierania zdalnej referencji. Jak mogliśmy się przekonać, byłby to niepotrzebny narzut wydajnościowy.
