A work manager acts as a thread pool for application components
that use asynchronous beans. Use the administrative console to configure
work managers.
Before you begin
If you are not familiar with work managers, refer to the Work
managers conceptual topic.
About this task
The work manager service is always enabled. In previous versions
of the product, the work manager service could be disabled using the
administration console or configuration service. The work manager
service configuration objects are still present in the configuration
service, but the enabled attribute is ignored.
You can define multiple
work managers for each cell. Each work manager is bound to a unique
place in Java Naming and Directory
Interface (JNDI).
Important: The work manager service
is only supported from within the Enterprise JavaBeans (EJB) Container or Web Container.
Looking up and using a configured work manager from a Java Platform, Enterprise Edition (Java EE) application client container is not
supported.
Procedure
- Start the administrative console.
- Select Resources > Asynchronous beans >
Work managers.
- Specify a Scope value and click New.
- Specify the required properties for work manager settings.
- Scope
- The scope of the configured resource. This value indicates the
location for the configuration file.
- Name
- The display name for the work manager.
- JNDI Name
- The Java Naming and Directory
Interface (JNDI) name for the work manager. This name is used by asynchronous
beans that must look up the work manager. Each work manager must have
a unique JNDI name within the cell.
- Number of Alarm Threads
- The maximum number of threads to use for processing alarms. Applies
to a separate thread pool that is used for running alarms. A single
thread is used to monitor pending alarms and dispatch them. An additional
pool of threads is used for dispatching the threads. All alarm managers
on the asynchronous beans associated with this work manager share
this set of threads. A single alarm thread pool exists for each work
manager, and all of the asynchronous beans associated with the work
manager share this pool of threads.
Avoid trouble: ![[Updated in September 2012]](../../delta.gif)
The number of alarm threads that you specify for this
property has no impact on the number of threads you specify for the
Minimum Number Of Threads and Maximum Number Of Threads properties.
The Number of Alarm Threads property only applies to the thread pool
for alarm threads. The Minimum Number Of Threads and Maximum Number
Of Threads properties only apply to the main thread pool that handles
work requests.
![[Updated in September 2012]](../../deltaend.gif)
sep2012
gotcha
- Minimum Number Of Threads
- Applies to the main thread pool for work submitted to the work
manager. The number of threads to be kept in the thread pool, created
as needed.
- Maximum Number Of Threads
- Applies to the main thread pool for work submitted to the work
manager. The maximum number of threads to be created in the thread
pool. The maximum number of threads can be exceeded temporarily when
the Growable check box is selected. These additional threads are discarded
when the work on the thread completes.
- Thread Priority
- The priority to assign to all threads in the thread pool.
Every
thread has a priority. Threads with higher priority are run before
threads with lower priority. For more information about how thread
priorities are used, see the Javadoc for the setPriority method of
the java.lang.Thread class in the Java Standard
Edition specification.
- [Optional] Specify a Description and a Category for the
work manager.
- [Optional] Select the Service Names (Java EE contexts) on which you want this work
manager to be made available. Any asynchronous beans that use this
work manager then inherit the selected Java EE
contexts from the component that creates the bean. The list of selected
services also is known as the "sticky" context policy for the work
manager. Selecting more services than are required might
impede performance.
Other optional fields include:
- Work timeout
- Specifies the number of milliseconds to wait before a scheduled
work object is released. If a value is not specified, then the timeout
is disabled.
- Work request queue size
- Specifies the size of the work request queue. The work request
queue is a buffer that holds scheduled work objects and can be a value
of 1 or greater. The thread pool pulls work from this queue. If you
do not specify a value or the value is 0, the queue size is managed
automatically. When the queue size is managed automatically, it is
computed as the (minimum_number_of_threads + maximum_number_of_threads)
/ 2. If this value computes to a zero value, a queue size of 1 is
used. Large values can consume significant system resources.
- Work request queue full action
- Specifies the action taken when the thread pool is exhausted,
and the work request queue is full. This action starts when you submit
non-daemon work to the work manager. If set to FAIL, the work manager
API methods creates an exception instead of blocking.
- Default transaction class
- Specifies the transaction class name used to classify work run
by this work manager instance when the z/OS® Work
Load Manager Service class information is not contained in the work
context information.
- Daemon transaction class
- Specifies the transaction class name used to classify "daemon"
work initiated by this work manager instance.
- Save your configuration.
Results
The work manager is now configured and ready for access by
application components that must manage the start of asynchronous
code.