Workload Management in WebLogic Server 9.0
Pages: 1, 2, 3, 4, 5

WebLogic WorkManager Configuration

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:

  1. The default fair share is not good enough.
  2. A response-time goal needs to be specified.
  3. A possibility of server-to-server deadlock exists, and a minimum threads constraint needs to be specified.
  4. Requests are bound by a common JDBC connection pool, and a maximum threads constraint needs to be specified.

Here are some guidelines on how to configure a WorkManager:

  1. WorkManagers can be application scoped by defining them in weblogic-application.xml. Keeping WorkManager configuration close to the application may help with portability.
  2. Decide if the components such as request classes and constraints in the WorkManager should be shared with other WorkManagers. If so, such components should be declared independently outside of the WorkManagers. Otherwise the components can be declared inside the WorkManager providing exclusive access.
  3. The WebLogic Server Administration Console provides screens for configuring WorkManagers and other related components. WorkManagers created through the console are available server-wide.

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:

  1. If the request class or constraint can be found within the application, then it is picked up.
  2. If (1) fails, then components at the server level are searched for a match.
  3. If (2) fails, then an exclusive default fair-share request class is created if the request class is being resolved. For constraint and capacity, a null value is returned which means that the WorkManager is unbounded in terms of the number of concurrent threads it gets to use and the number of requests it can enqueue.

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.

Setting the Dispatch Policy

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:

  1. If a WorkManager with the dispatch-policy name can be found within the same application, it is resolved to that.
  2. If (1) fails, then a WorkManager match is attempted at the server level.
  3. If (2) fails, then a warning message is printed in the server logs, and the application default WorkManager is used.

Here is how to set a dispatch policy in a servlet in web.xml:

<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 MyAppScopedWorkManager-1 WorkManager.

Here is another use of the dispatch-policy element, in weblogic-ejb-jar.xml:

<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-1 and MyAppScopedWorkManager-2, which are WorkManagers defined at the application level in the previous section.

Pages: 1, 2, 3, 4, 5

Next Page ยป