what is Work Managers in Weblogic Server?

Work Managers:

WebLogic Server is self-tuning in nature by default, that is, it adjusts the thread size as needed.
WebLogic Server uses a single thread pool whose size changes automatically to maximize throughput. This process is called server self-tuning. The queue monitors throughput over time and based on history and determines whether to adjust the thread count. The server increases or decreases pool size if a higher or lower thread count increases performance. All the work is executed within this pool.
WebLogic Server prioritizes work based on rules defined by an administrator and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool. This new strategy makes it easier for administrators to allocate processing resources and manage performance, avoiding the effort and complexity involved in configuring, monitoring, and tuning custom executes queues.

Default Work Manager:

•  All applications are given equal priority.
•  A default fair share of threads is given to each application.
•  If no Work Manager is explicitly assigned to an application, it uses the default Work Manager.
•  The default Work Manager can be overridden by creating and configuring a global Work Manager called default.
Work Manager Scheduling Guidelines:
•  Use when the default fair share is insufficient.
•  Use to schedule work based on application priority.
•  Use when applications require different response times.
•  Use to avoid server deadlocks.

Components of Work Manager:

–  Request Classes.
–  Constraints.
Request Classes:
Request classes help schedule work based on priority.
Three types of request classes:
•  fair-share-request-class
•  response-time-request-class
•  context-request-class
Fair Share Request Class:
The fair share request class specifies the average percentage of thread-use time required to process requests.
•  Configuration options: Name and Fair share value
•  Default value: 50
•  Minimum value: 1
•  Maximum value: 1000
Fair Share Request Class
The fair share request class specifies the average percentage of thread-use time required to process requests.
Snippet: high priority fair share request class
fair-share-request-class>
<name>high_priority</name>
<fair-share>90</fair-share>
</fair-share-request-class>
Snippet: low priority fair share request class
<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>
Response Time Request Class:
The response time request class specifies a response time goal in milliseconds.
•  Configuration options: Name and Goal (milliseconds)
•  Default value: 0
Snippet: fast response request class <ModuleA>
<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>1000</goal-ms>
</response-time-request-class>
Snippet: slow response request class <ModuleB>
<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>8000</goal-ms>
</response-time-request-class>
Context Request Class:
The context request class assigns request classes to requests based on context information, such as the current user or the current user’s group.
•Configuration options: Name and context case
Snippet: context request class
<context-request-class>
<name>simple_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>

</context-case>
</context-request-class>
Constraints:
•  A constraint defines:
–  The minimum and maximum numbers of threads allocated to execute requests
–  The total number of requests that can be queued or executing before WebLogic Server begins rejecting requests
• Types of constraints:
–  max-threads-constraint
–  min-threads-constraint
–  capacity.
Maximum Threads Constraints:
The maximum threads constraint limits the number of concurrent threads that can execute requests sharing this constraint.
Configuration options:
–  Name: The user-specified name
–  Count: Thread count (Default value: -1)
– Data Source: The name of the connection pool whose size is taken as the maximum constraint
Snippet: maximum threads constraint
<max-threads-constraint>
<name>max_threads</name>
<count>10</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>
Minimum Threads Constraints:
The minimum threads constraint guarantees a minimum number of concurrent threads that the server allocates to requests sharing this constraint.
Configuration options:
–  Name: The user-specified name.
–  Count: Thread count (Default value: -1)
Snippet: minimum threads constraint
<min-threads-constraint>
<name>min_threads</name>
<count>1</count>
</min-threads-constraint>
Capacity Constraints:
The capacity constraint causes the server to reject requests only when it has reached its capacity to avoid server deadlocks.
Configuration options:
–  Name: The user-specified name
–  Count: Thread count (Default value: -1)
Snippet: capacity constraint
<capacity-constraint>
<name>my_capacity</name>
<count>50</count>
</capacity-constraint>
Referencing Classes or Constraints:
A Work Manager is defined by encapsulating one request class and/or one constraint to schedule requests.
Configuration options:
–  Name and request class/constraint
Snippet: Work Manager
<work-manager>
<name>priority_work_manager</name>
<fair-share-request-class>
<name>very_high_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>min_five_Threads</name>
<count>5</count>
<min-threads-constraint>
</work-manager>