The minimum threads constraint is another component of a WorkManager, much like a request class. This constraint should be used in very special cases and should not be confused with the thread count parameter in execute queues. The minimum threads constraint takes an integer value that specifies the number of threads that should be assigned to this constraint to prevent server-to-server deadlocks. Usually, all WorkManagers use threads from the common thread pool, and the proportion of thread usage by different WorkManagers is determined by the request class component defined in the previous sections. Threads are dynamically added to the common thread pool to maximize the overall server throughput.
There are special situations where two servers can deadlock if a WorkManager does not get a minimum number of threads. For example, consider when Server A makes an EJB call to Server B, and Server B in turn makes a callback to Server A as a part of the same request processing. In this case, we know that until Server A responds to the callback from Server B, its original request to Server B will not get serviced. This scenario can be addressed in two ways. Configuring a WorkManager in Server A with a high fair share for callback requests from Server B will ensure that those requests get higher priority than new requests arriving at Server A from clients. In addition, adding a minimum threads constraint clause to the WorkManager will ensure that at least some threads in Server A will be able to pick up callback requests from Server B even when all the threads are busy or deadlocked.
A minimum threads constraint is specified like this:
<work-manager> <name>MyWorkManager</name> <min-threads-constraint> <name>minthreads</name> <count>3</count> </min-threads-constraint> </work-manager>
The maximum threads constraint can be used to limit the maximum number of concurrent threads given to all WorkManagers that share the constraint. Like the minimum threads constraint, the maximum threads constraint should be used only in special circumstances. Normally, the request classes get their fair share of thread resources, and the maximum number of threads in the common thread pool is limited by throughput considerations. Threads are not added if there is no benefit in overall server throughput. There are cases when the administrator/deployer knows that the maximum number of concurrent threads is bound by the maximum capacity of the JDBC connection pool. For example, all servlet or EJB requests that use a common JDBC connection pool are bound by its maximum pool size. In such circumstances, it is possible to define a maximum threads constraint that refers to the JDBC connection pool. This maximum threads constraint is then shared by all WorkManagers affected by the connection pool size. Here is an example of a maximum threads constraint that uses a JDBC connection pool:
<work-manager> <name>MyDataSourceBoundWorkManager</name> <max-threads-constraint> <name>pool_constraint</name> <pool-name>AppScopedDataSource</pool-name> </max-threads-constraint> </work-manager>
AppScopedDataSource refers to the name of the data source that is either application scoped or defined at the server level. The maximum threads constraint changes dynamically as the maximum connection pool size changes.
The maximum threads constraint can also be specified as a number:
<work-manager> <name>MyWorkManager</name> <max-threads-constraint> <name>ejb_maxthreads</name> <count>5</count> </max-threads-constraint> </work-manager>
The capacity constraint defines the maximum number of requests that can be queued or are executing at any given point in time. Only requests waiting for threads or those currently under execution are counted. Capacity can be shared across multiple WorkManagers. This means that all WorkManagers that share the capacity are bound by the common limit. Overload action is taken after the capacity is reached. For example, work is refused with a well-known HTTP response code like 503 or a RemoteException in case of RMI calls permitting cluster failover. Overload protection in WebLogic Server 9.0 will be discussed in a forthcoming dev2dev article. Capacity is specified like this:
<work-manager> <name>MyWorkManager</name> <capacity> <name>MyCapacity</name> <count>10</count> </capacity> </work-manager>
In the previous sections, I explained scheduling based on policies such as fair share and response time by relating the scheduling to other work using the same policy. This section explains how different types of policies like request classes and constraints interact with each other.