Configure EJB asynchronous methods using scripting

Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop EJB applications > Develop session beans > Configure EJB 3.1 session bean methods to be asynchronous

Configure EJB asynchronous methods using scripting

Overview

EJB asynchronous method behavior is configured using the EJBAsync configuration object in server.xml. Each server in a multiple-server environment has its own EJBAsync configuration object and must be configured individually.

Procedure
Launch wsadmin.

Determine attributes to be updated...

Attribute Description
maxThreads Maximum number of threads used in the execution of asynchronous EJB methods. Default is 5.
workReqQSize Size of the work request queue, which is a buffer that holds requested asynchronous methods until a thread is available to run them on.

maxThreads | workReqQSize = max allowable in progress method requests

For example, if the maxThreads is set to 5 threads, and the workReqQSize is set to 50, then the total number of allowable in-progress method requests is 55.
Default is 0, indicating that the queue size is managed by the runtime environment. The run time currently uses the larger of 20 and maxThreads.
workReqQFullAction Action taken when the thread pool is exhausted, and work request queue is full.
If set to 1, an exception occurs instead of waiting for a thread, or a place in the queue, to become available.
If set to 0, the thread that is requesting the asynchronous method execution waits until a thread, or place in the queue, becomes available.
Default is 0.
customWorkManagerJNDIName JNDI name used to look up the custom defined work manager in the namespace.
Default is null.
useCustomDefinedWM Whether a custom-defined work manager instance is used, or the default internal work manager instance.
When the useCustomDefinedWM attribute is set to true, this means that a custom work manager instance is used. In this case, the customWorkManagerJNDIName attribute must be set, and all other attributes are ignored.
When the useCustomDefinedWM attribute is set to false, the default, internal work manager instance is used. In this case, the customWorkManagerJNDIName attribute is ignored, and all other attributes are used to help configure the default work manager instance.
Default is false.
futureTimeout Amount of time, in seconds, that the server-side future object, which is created as a result of running a fire-and-return asynchronous method, is available. The server-side future object is not valid after you call the get() method, and a value is returned to the remote client.
To avoid memory leaks, call the get() method on the future object, or specify a positive and non-zero future duration value.
A future duration value of zero indicates that the future object never times out.
Default is 86400, which means that the future object expires and gets cleaned up by the application server after 24 hours and is no longer available.
A org.omg.CORBA.OBJECT_NOT_EXIST exception is thrown when a call to the get() method is made after the future object expires.
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.
This attribute might affect the number of future objects on the server. Use the AsynchFutureObjectCount PMI statistic to determine the count of open FutureObjects on the server, which can help you determine whether applications are accumulating future objects without calling the get() method on those objects.
Obtain a reference to the correct EJBAsync configuration object and store it in a variable.
### Jacl
set async [$AdminConfig list EJBAsync]

### Jython:
async = AdminConfig.list('EJBAsync')
If we have a multiple-server environment, then multiple EJBAsync configuration objects are returned. Programmatically loop over the list and select the EJBAsync configuration object that corresponds to the server update.
In a multiple-server environment, as an alternative to programmatically looping over the list of EJBAsync objects, you can manually select the correct EJBAsync object and copy and paste it into your variable.
We can copy and paste the reference for the needed EJBAsync object into your variable.
### Jacl
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"

### Jython:
async = "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
Update attributes on the EJBAsync configuration object.
Update attributes on the EJBAsync configuration object using the AdminConfig modify command. As input to the command, specify the EJBAsync reference that you obtained in the previous step, and a list of attributeName and attributeValue combinations.
To set a max thread count of 10 threads, a queue size of 15, and a futureTimeout of 3600 seconds:
### Jacl
set update "{maxThreads 10} {workReqQSize 15} {futureTimeout 3600}" $AdminConfig modify $async $update
$AdminConfig save set sync1 [$AdminControl completeObjectName type=NodeSync,node=
<your node>,*]
$AdminControl invoke $sync1 sync
                      
### Jython:
AdminConfig.modify(async, '[ [maxThreads "10"] [workReqQSize "15"] [futureTimeout "3600"] ]')
AdminConfig.save()
sync1 = AdminControl.completeObjectName('type=NodeSync,node=
<your node>,*')
AdminControl.invoke(sync1, 'sync')
Related

EJB asynchronous methods settings
Enterprise bean counters
Configure remote asynchronous EJB method results

+
Search Tips | Advanced Search

Attribute	Description
maxThreads	Maximum number of threads used in the execution of asynchronous EJB methods. Default is 5.
workReqQSize	Size of the work request queue, which is a buffer that holds requested asynchronous methods until a thread is available to run them on. maxThreads \| workReqQSize = max allowable in progress method requests For example, if the maxThreads is set to 5 threads, and the workReqQSize is set to 50, then the total number of allowable in-progress method requests is 55. Default is 0, indicating that the queue size is managed by the runtime environment. The run time currently uses the larger of 20 and maxThreads.
workReqQFullAction	Action taken when the thread pool is exhausted, and work request queue is full. If set to 1, an exception occurs instead of waiting for a thread, or a place in the queue, to become available. If set to 0, the thread that is requesting the asynchronous method execution waits until a thread, or place in the queue, becomes available. Default is 0.
customWorkManagerJNDIName	JNDI name used to look up the custom defined work manager in the namespace. Default is null.
useCustomDefinedWM	Whether a custom-defined work manager instance is used, or the default internal work manager instance. When the useCustomDefinedWM attribute is set to true, this means that a custom work manager instance is used. In this case, the customWorkManagerJNDIName attribute must be set, and all other attributes are ignored. When the useCustomDefinedWM attribute is set to false, the default, internal work manager instance is used. In this case, the customWorkManagerJNDIName attribute is ignored, and all other attributes are used to help configure the default work manager instance. Default is false.
futureTimeout	Amount of time, in seconds, that the server-side future object, which is created as a result of running a fire-and-return asynchronous method, is available. The server-side future object is not valid after you call the get() method, and a value is returned to the remote client. To avoid memory leaks, call the get() method on the future object, or specify a positive and non-zero future duration value. A future duration value of zero indicates that the future object never times out. Default is 86400, which means that the future object expires and gets cleaned up by the application server after 24 hours and is no longer available. A org.omg.CORBA.OBJECT_NOT_EXIST exception is thrown when a call to the get() method is made after the future object expires. 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. This attribute might affect the number of future objects on the server. Use the AsynchFutureObjectCount PMI statistic to determine the count of open FutureObjects on the server, which can help you determine whether applications are accumulating future objects without calling the get() method on those objects.