Before I discuss more about how to configure WorkManagers for your application, it is important to note that the default configuration may be good enough. As mentioned earlier, each application gets its own WorkManager with its own default fair share. This means that all applications are treated with equal importance, and applications are prevented from hogging threads. WorkManagers can be configured and associated with requests overriding the default for the following reasons:
Here are some guidelines on how to configure a WorkManager:
weblogic-application.xml. Keeping WorkManager configuration close to the application may help with portability.
As mentioned earlier, WorkManagers can be application scoped or defined globally. WorkManagers can refer by name to independently defined components such as request classes and constraints. The name resolution is handled as follows:
Note that the names used while referring to the WorkManager components are the ones defined in the deployment descriptors and not JNDI names. Here is an example of WorkManager configuration defined in an application:
<weblogic-application> ... <max-threads-constraint> <name>MyConstraint</name> <pool-name>MyDataSource</pool-name> </max-threads-constraint> ... <work-manager> <name>MyAppScopedWorkManager-1</name> <fair-share-request-class> <name>high_fairshare</name> <fair-share>80</fair-share> </fair-share-request-class> <max-threads-constraint-name>MyConstraint </max-threads-constraint-name> </work-manager> <work-manager> <name>MyAppScopedWorkManager-2</name> <fair-share-request-class> <name>high_fairshare</name> <fair-share>20</fair-share> </fair-share-request-class> <max-threads-constraint-name>MyConstraint </max-threads-constraint-name> </work-manager> ... </weblogic-application>
Note how the two WorkManagers are sharing the same maximum threads constraint by referring to the constraint by name.
Now that we've looked at configuring WorkManagers, let's examine how to link a WorkManager with requests. You can do this by defining a dispatch-policy. For servlets, this is accomplished by setting a dispatch-policy initialization parameter; for EJBs you have to use the
dispatch-policy element that existed in the earlier releases. In the earlier releases, the dispatch policy referred to the name of an execute queue. In WebLogic Server 9.0, the same
dispatch-policy element is used to refer to WorkManagers. The dispatch-policy resolution happens as follows:
dispatch-policyname can be found within the same application, it is resolved to that.
Here is how to set a dispatch policy in a servlet in
<web-app> <servlet> <servlet-name>WorkServlet</servlet-name> <servlet-class>workservlet.WorkServlet</servlet-class> <init-param> <param-name>wl-dispatch-policy</param-name> <param-value>MyAppScopedWorkManager-1</param-value> </init-param> </servlet> </web-app>
The configuration means that all
WorkServlet invocations should use the
Here is another use of the
dispatch-policy element, in
<weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>WorkEJB</ejb-name> <jndi-name>WorkEJB</jndi-name> <dispatch-policy>MyAppScopedWorkManager-2</dispatch-policy> </weblogic-enterprise-bean> ... </weblogic-ejb-jar>
The two examples above use
MyAppScopedWorkManager-2, which are WorkManagers defined at the application level in the previous section.