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 Java Beans (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 need to 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. 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.
- Minimum Number Of Threads
- The number of threads to be kept in the thread pool, created as needed.
- Maximum Number Of Threads
- The maximum number of threads to be created in the thread pool. The maximum
number of threads can be exceeded temporarily if 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 actually 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 need to manage the start of asynchronous code.