maxThreads |
Specifies the maximum number of threads that
are used in the execution of asynchronous EJB methods. The default
value is 5.
|
workReqQSize |
Specifies the size of the work request queue.
The work request queue is a buffer that holds requested asynchronous
methods until a thread is available to run them on.
The sum of the maxThreads and the workReqQSize
attributes is the total number of 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.
The
default value 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 |
Specifies the 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.
The
default value is 0.
|
customWorkManagerJNDIName |
Specifies the Java Naming
and Directory Interface (JNDI) name used to look up the custom defined
work manager in the namespace.
The default value is null.
|
useCustomDefinedWM |
Specifies 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.
The default value is false.
|
futureTimeout |
Specifies the 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, you
must 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.
The
default value 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.
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. sptcfg
Supported configurations: 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.
See the topic, Enterprise bean counters, for more information. sptcfg
|