A customer needs to ensure that the number of threads servicing an application does not exceed the number of database connections available to the…

To manage work in your applications, you define one or more of the following Work Manager

components:

Fair Share Request Class:

Response Time Request Class:

Min Threads Constraint:

Max Threads Constraint:

Capacity Constraint

Context Request Class:

Note:

* max-threads-constraint—This constraint limits the number of concurrent threads executing

requests from the constrained work set. The default is unlimited. For example, consider a constraint

defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that

not more than 10 threads are executing requests from the three entry points combined.

A max-threads-constraint can be defined in terms of a the availability of resource that requests

depend upon, such as a connection pool.

A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair

share of threads or meeting its response time goal. Once the constraint is reached the server does

not schedule requests of this type until the number of concurrent executions falls below the limit.

The server then schedules work based on the fair share or response time goal.

* WebLogic Server prioritizes work and allocates threads based on an execution model that takes

into account administrator-defined parameters and actual run-time performance and throughput.

Administrators can configure a set of scheduling guidelines and associate them with one or more

applications, or with particular application components.

* WebLogic Server uses a single thread pool, in which all types of work are executed. WebLogic

Server prioritizes work based on rules you define, 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.

The common thread pool changes its size automatically to maximize throughput. The queue

monitors throughput over time and based on history, determines whether to adjust the thread

count. For example, if historical throughput statistics indicate that a higher thread count increased

throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads

did not reduce throughput, WebLogic decreases the thread count. 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.

Reference: Using Work Managers to Optimize Scheduled Work