EJB asynchronous methods settings

Use this page to modify settings on the work manager used in support of Enterprise JavaBeans asynchronous methods.

To view this administrative console page, click Servers > Server Types > WebSphere application servers > server_name > EJB Container Settings > EJB asynchronous method invocation settings

The Use internal work manager instance and Use custom work manager instance options are mutually exclusive.

Use this work manager for asynchronous methods

Specifies a default work manager instance.

The product provides an internal work manager instance for support of EJB asynchronous methods. The internal work manager instance is pre-configured for basic EJB asynchronous method functionality, and provides limited configuration settings.

Clicking this button specifies that you want to use the internal work manager instance to manage your asynchronous method invocations. Selecting this choice precludes the Use custom work manager instance option.

The Use internal work manager instance option is the default. Alternatively, you can use a custom-defined work manager instance.

Use custom work manager instance

Specifies a custom-defined work manager instance.

You can provide a more advanced configuration for EJB asynchronous methods by defining a custom work manager instance.

Selecting this choice allows you to use a work manager instance that you have already defined and configured in a way that is optimal for your environment.

Selecting this choice precludes the Use internal work manager instance option.

Maximum number of threads

Specifies the maximum number of threads that are used in the execution of asynchronous EJB methods. The default is 5.

Work request queue size

Specifies the size of the work request queue. The work request queue is a buffer that holds requested that asynchronous methods until a thread is available to run them on. The default is 0, indicating that the initial size is half way between the minimum and maximum number of threads.

The sum of the maximum number of threads and the work request queue size attributes is the total number of allowable in-progress method requests.

For example, if the maximum number of threads is set to five threads, and the work request queue size is set to 50, then the total number of allowable in-progress method requests is 55.

The default value is 0, indicating that the queue size is managed by the runtime environment. The runtime currently uses the larger of 20 and maxThreads.

Work request queue full action

Specifies the action taken when the thread pool is exhausted, and the work request queue is full. The default is BLOCK.

If set to FAIL, an exception occurs instead of waiting for a thread, or a place in the queue, to become available.

You might want to use this option during development to help identify errors caused by long-running asynchronous methods. You might also use it to help determine the number of threads and queue size that should be configured.

If set to BLOCK, the thread that is requesting that the asynchronous method execution waits until a thread, or a place in the queue, becomes available.

Work Manager JNDI name

Specifies the Java™ Naming and Directory Interface (JNDI) name used to look up the custom-defined work manager in the namespace.

Remote future object duration

Specifies the amount of time that the server retains the future object of each fire-and-return-results asynchronous method call. If an application does not retrieve the results within the specified period of time, the server purges the results of that method call to prevent memory leakage and a potential OutOfMemory error. You can specify 0 to never purge the objects; however, specifying a zero value means that the future object never times out and you disable protection from incorrectly written programs that might cause the referenced OutOfMemory error. The default value is 86400 seconds (24 hours).

Avoid trouble: If you call the get() or the get(time) method on the future object, then you might decrease performance because blocking can occur until either the work is done or until the specified time has passed. Therefore, to avoid blocking on the get(..) methods, call the isDone() method, which returns immediately. Then, call the get() method after the isDone() method returns true.
Supported configurations: This value is only applicable for clients that call the enterprise bean using a remote business interface, the value is not used for local business interface or no-interface views. When the asynchronous work has completed, the server sets an alarm for the duration specified to the server-side future object. When the alarm is activated, the server releases all the resources associated with the future object, making it unavailable to the client. If the client calls the get() method on the future object before the duration amount of time, the alarm is canceled and all the resources associated with the future object are released.