WAS v8.5 > Reference > SetsEJB asynchronous methods settings page
Use this page to modify settings on the work manager used in support of Enterprise JavaBeans asynchronous methods.
To view this dmgr 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
Default work manager instance.
WAS v8.5 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 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, we can use a custom-defined work manager instance.
Use custom work manager instance
Custom-defined work manager instance.
We 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 we have already defined and configured in a way that is optimal for the environment.
Selecting this choice precludes the Use internal work manager instance option.
Maximum number of threads
Maximum number of threads used in the execution of asynchronous EJB methods. The default is 5.
Work request queue size
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 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.
Default is 0, indicating the queue size is managed by the runtime environment. The runtime currently uses the larger of 20 and maxThreads.
Work request queue full action
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 the asynchronous method execution waits until a thread, or a place in the queue, becomes available.
Work Manager JNDI name
JNDI name used to look up the custom-defined work manager in the namespace.
Remote future object duration
Amount of time 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 exception. We can specify 0 to never purge the objects; however, specifying a zero value means the future object never times out and you disable protection from incorrectly written programs that might cause the referenced OutOfMemory exception. Default is 86400 seconds (24 hours).
If we 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. gotcha
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..
Related
Configure EJB asynchronous methods using scripting
Configure remote asynchronous EJB method results