Warteschlangen für EJB-Methodenaufrufe
Methodenaufrufe für Enterprise-Beans werden nur in die Warteschlange gestellt, wenn sie von fernen Clients stammen. Ein ferner Client wäre zum Beispiel ein EJB-Client, der in einer anderen Java Virtual Machine (einem anderen Adressraum) als die Enterprise-Bean ausgeführt wird. Wenn der EJB-Client, d. h., ein Servlet oder eine andere Enterprise-Bean, jedoch auf der JVM installiert ist, auf der die EJB-Methode ausgeführt wird, und in demselben Ausführungs-Thread wie die EJB-Methode läuft, wird die Anforderung nicht in eine Warteschlange gestellt.
Ferne Enterprise-Beans kommunizieren mit über RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) miteinander. Über RMI/IIOP eingeleitete Methodenaufrufe werden von einem serverseitigen ORB verarbeitet. Der Thread-Pool fungiert als Warteschlange für eingehende Anforderungen. Wenn jedoch ein ferner Methodenaufruf abgesetzt wird und im Thread-Pool keine Threads mehr verfügbar sind, wird ein neuer Thread erstellt. Ist die Methodenanforderung vollständig verarbeitet, wird der Thread zerstört. Wird der ORB für die Verarbeitung ferner Methodenanforderungen verwendet, ist der EJB-Container aufgrund der unbegrenzten Threads eine offene oder geschlossene Warteschlange.
In der folgenden Abbildung sind die
beiden Warteschlangenoptionen für Enterprise-Beans dargestellt.

In der folgenden Abbildung sind die
beiden Warteschlangenoptionen für Enterprise-Beans dargestellt.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- Analyse der Aufrufmuster des EJB-Clients.
Bevor Sie den Thread-Pool konfigurieren, sollten Sie sich mit den Aufrufmustern des EJB-Client beschäftigt haben. Wenn ein Servlet eine kleine Anzahl von Aufrufen für ferne Enterprise-Beans absetzt und die Methodenaufrufe relativ kurz sind, sollten Sie für den Thread-Pool des ORB weniger Threads konfigurieren als für den Thread-Pool des Web-Containers.
In welchem Maße der Wert für den Thread-Pool des ORB erhöht werden muss, hängt direkt von der Anzahl der Servlets (Clients) ab, die gleichzeitig Enterprise-Beans aufrufen, sowie von der Dauer der einzelnen Methodenaufrufe. Wenn die Methodenaufrufe länger dauern oder die Anwendungen viel Zeit für den ORB aufwenden, sollten Sie die Größe des ORB-Thread-Pools an den Wert für den Webcontainer angleichen. Sind die an den ORB gerichteten Aufrufe des Servlet nur von kurzer Dauer, kann das Servlet potenziell einen ORB-Thread für mehrere Aufrufe verwenden. In diesem Fall muss der Thread-Pool des ORB nicht groß sein. Die Hälfte des Webcontainer-Thread-Pools wäre ausreichend.
- Überwachung des Prozentsatzes konfigurierter und verwendeter Threads.
Anhand der Option Grenzwert in Prozent des Tivoli Performance Viewer können Sie bestimmen, für wie lange alle konfigurierten Threads genutzt werden. Ein Wert, der sich ständig im zweistelligen Bereich bewegt, weist auf einen Engpass beim ORB hin. Erhöhen Sie die Anzahl der Threads.