As mentioned above, WebLogic Server 9.0 maps incoming requests to a WorkManager instead of executing queues. Let's now look at what a WorkManager is and does. A WebLogic WorkManager is the runtime abstraction into which requests are submitted by WebLogic Server containers for asynchronous execution. Multiple WorkManagers can be present, and the choice of which WorkManager to use is determined during deployment. Administrators can change the WorkManager for any servlet or EJB dispatch by using deployment descriptors. This is described in more detail in the WorkManager Configuration section on page 4. Each WorkManager can contain four types of components:
It is important to note a couple of things before we proceed. These four components are optional. In addition, the components can be shared between WorkManagers. For example, two or more WorkManagers can share the same request class, which means that they get the same internal priority. Another simple example could be when WorkManagers share the same capacity. This means that the sum total of requests from all WorkManagers that share the capacity will not exceed the specified limit.
The term WebLogic WorkManager is used to purposefully differentiate it from the Timer and WorkManager specification. The relationship between the two is explained in the Timer and WorkManager Specification Support section.
Now let's look at each of the four components in more detail.
A request class defines a class of requests. Requests that share the same runtime execution behavior should be a part of the same request class. The "same runtime behavior" could mean many things. Examples include multiple invocations of the same servlet, the module, or the entire application. By default, each application belongs to its own unique request class. All requests that share a request class get the same runtime priority. They are treated as one single type by the WebLogic scheduler. Three types of request classes can be defined:
It is important to note that a WorkManager can have just one kind of request class and not more.
This request class takes a simple integer value that denotes a fair share. The value can range from 1 to 1000. Thread usage become higher as the fair share number increases. Fair shares are relative to other fair shares defined in the system. Fair shares are reflected in scheduling logic such that as long as multiple fair shares compete, the average thread usage by each is in proportion to its fair share.
For example, consider a situation in which we only have two fair shares, A and B, having a fair share of 80 and 20, respectively. During a period in which both fair shares are sufficiently requested, say, zero think time and more clients than threads, the probability that a thread will work on behalf of A or B will tend toward 80 percent or 20 percent, respectively. The scheduling logic ensures this even when A tends to use a thread for much longer than B.
A WorkManager without a fair share request class gets its own exclusive fair share of 50.
Here is an example of a WorkManager with a fair share request class. This WorkManager is defined in
weblogic-application.xml. It is also important to note that request classes can be defined outside the WorkManager and then referred by the WorkManagers using the request class name.
<work-manager> <name>highfairshare_workmanager</name> <fair-share-request-class> <name>high_fairshare</name> <fair-share>80</fair-share> </fair-share-request-class> </work-manager>
The response-time goal request class takes an integer value that specifies the response-time goal in milliseconds. Response-time goals are relative to other response goals and fair shares. Response-time goals can be used to differentiate request classes. We do not try to meet a response-time goal for an individual request. Rather we compute a tolerable waiting time for a request class by subtracting the observed average thread use time. Then we schedule requests so that the average wait for each request class is in proportion to their tolerable waiting time. For example, consider when we only have two request classes, A and B, with response-time goals 2000 ms and 5000 ms, respectively, where the time an individual request uses a thread is much smaller. During a period in which both request classes are sufficiently requested, say, zero think time and more clients than threads, we schedule to keep the average response time in the ratio 2:5 so that it is a common fraction or multiple of the stated goal.
Here is an example of a WorkManager with a response-time request class:
<work-manager> <name>fast_response_time</name> <response-time-request-class> <name>fast_response_time</name> <goal-ms>2000</goal-ms> </response-time-request-class> </work-manager>
This is a compound request class that provides a mapping between the request context and the above two request classes. We currently look at the security name of the user submitting the request and the security group the user belongs to. During work schedule, the exact request class is determined by looking at this security context information. For example, a context request class can be defined such that all users of a "platinum" group get a high fair share while the rest of the users get a lower fair share. Here is an example configuration:
<work-manager> <name>context_workmanager</name>" <context-request-class> <name>test_context</name> <context-case> <user-name>platinum_user</user-name> <request-class-name>high_fairshare</request-class-name> </context-case> <context-case> <user-name>evaluation_user</user-name> <request-class-name>low_fairshare</request-class-name> </context-case> </context-request-class> </work-manager>
In the example above, a WorkManager is defined with a context request class. The request class has two mappings—one for a platinum user and the other for an evaluation user—and we assume these two users are configured in the WebLogic Server security realm. The mapping states that all platinum users should use the high fair share request class while evaluation users should use the low fair share request class. Note that "high_fairshare" and "low_fairshare" are the names of two fair share request classes defined either at the same level in the application or globally at the server level.