A work manager is a thread pool created for J2EE applications that use asynchronous beans.
Using the administrative console, an administrator can configure any number of work managers. The administrator specifies the properties of the work manager, including the inheritance context policy for any asynchronous beans that use the work manager. The administrator binds each work manager to a unique place in Java Naming and Directory Interface (JNDI).
When writing a Web or EJB component that uses asynchronous beans, the developer should include a resource reference in each component that needs access to a work manager. (For more information on resource references, see the topic References.) The component looks up a work manager using a logical name in the component's java:comp namespace, just as it looks up a data source, enterprise bean, or connection factory.
The deployer binds physical work managers to logical work managers when the application is deployed.
For example, if a developer needs three thread pools to partition work between bronze, silver, and gold levels, the developer writes the component to pick a logical pool based on an attribute in the client application profile. The deployer has the flexibility to decide how to map this request for three thread pools. The deployer might decide to use a single thread pool on a small machine. In this case, the deployer binds all three resource references to the same work manager instance (that is, the same JNDI name). A larger machine might support for three thread pools, so the deployer binds each resource reference to a different work manager. Work managers can be shared between multiple J2EE applications installed on the same server.
An application developer can use as many logical work managers as necessary; the deployer chooses whether to map one physical work manager or several to the logical work manager defined in the application.
All J2EE components that need to share asynchronous scope objects must use the same work manager. These scope objects have an affinity with a single work manager so an application that uses AsynchScopes should verify that all of the components using scope objects use the same work manager.
When multiple work managers are defined, the underlying thread pools are created in a JVM only if an application within that Java virtual machine (JVM) looks up the work manager. For example, there might be ten thread pools (work managers) defined, but none are actually created until an application looks these pools up.
How to look up a work manager
An application can look up a work manager as follows. Here, the component contains a resource reference named wm/myWorkManager, which was bound to a physical work manager when the component was deployed:
InitialContext ic = new InitialContext(); WorkManager wm = (WorkManager)ic.lookup("java:comp/env/wm/myWorkManager");
Inheritance J2EE contexts
Asynchronous beans can inherit the following J2EE contexts.
The contexts that can be inherited depends on the work manager used by the application that creates the asynchronous bean. Using the administrative console, the administrator defines the sticky context policy of a work manager by selecting the services on which the work manager is to be made available.