Enterprise bean method invocation queuing

Method invocations to enterprise beans are queued only for remote clients that make the method call. An example of a remote client is an enterprise bean client running in a separate Java virtual machine (JVM) (another address space) from the enterprise bean. In contrast, no queuing occurs if the enterprise bean client, either a servlet or another enterprise bean, is installed in the same JVM on which the enterprise bean method runs and on the same thread of execution as the enterprise bean client.

Remote enterprise beans communicate with the Remote Method Invocation over an Internet Inter-Orb Protocol (RMI-IIOP). Method invocations initiated over RMI-IIOP are processed by a server-side object request broker (ORB). The thread pool acts as a queue for incoming requests. However, if a remote method request is issued and there are no more available threads in the thread pool, a new thread is created. After the method request is completed, the thread is destroyed. Therefore, when the ORB processes remote method requests, the EJB container is an open queue, due to the use of unbounded threads. This graphic illustrates the two queuing options for enterprise beans.

Review this information about using enterprise bean queuing to improve performance:

• Analyze the calling patterns of the enterprise bean client.
  When you configure the thread pool, it is important to understand the calling patterns of the enterprise bean client. If a servlet is making a small number of calls to remote enterprise beans and each method call is relatively brief, consider setting the number of threads in the ORB thread pool to a value lower than the Web container thread pool size value.

  

  The degree to which the ORB thread pool value needs to be increased is a function of the number of clients (or sevlets) that simultaneously call enterprise beans, and of the duration of each method call. If the method calls are longer or the applications spend a lot of time in the ORB, consider making the ORB thread pool size equal to the Web container size. If the servlet makes only short-lived or quick calls to the ORB, servlets can potentially reuse the same ORB thread. In this case, the ORB thread pool can be as small as one-half of the thread pool size setting for the Web container.

• Monitor the percentage of configured threads in use.
  Tivoli Performance Viewer shows a metric called percent maxed, which is used to determine how often the configured threads are used. A value that is consistently in the double-digits indicates a possible bottleneck at the ORB. To remove the bottleneck, increase the number of threads.