3.6.1 Mechanism of dynamically changing the number of concurrent executions
The following figure shows an overview of dynamically changing the number of concurrent threads in CTM.
|
|
![[Figure]](GRAPHICS/ZU031500.GIF)
The following subsections describe Figure 3-15.
- Organization of this subsection
(1) Initial status (number of concurrent executions is 5)
This subsection describes the status existing when a J2EE server is started before the number of concurrent executions is changed dynamically. The schedule queue managed by the CTM daemon is shared by the J2EE applications on J2EE servers 1 and 2.
For the J2EE application on J2EE server 1, the number of concurrent executions (parallel count) is set to 3 as a stateless session bean property. For the J2EE application on J2EE server 2, the number of concurrent executions (parallel count) is set to 2 as a stateless session bean property. In this case, the number of concurrent executions for the schedule queue is 5 (3 + 2).
When the CTM daemon receives a request, threads for executing the request are generated as needed on both J2EE servers. No more threads than the value set by parallel count for the J2EE application can be generated. The generated threads are made resident in memory (not deleted).
Note that the parallel count value can be set or changed by using server management commands.
(2) After the number of concurrent executions changes dynamically (from 5 to 8)
This subsection describes how the system behaves if the number of concurrent executions for a schedule queue dynamically changes to 8.
If the number of concurrent executions for a schedule queue increases dynamically, the number of resident threads that process the requests for each J2EE application increases accordingly.
Note that if the number of resident threads changes, the number of resident threads for each J2EE application that shares the schedule queue is balanced. This process is called balancing the number of resident threads. For example, assume that three J2EE servers contain J2EE application instances whose parallel count values are 40, 30, and 60, and as many resident threads as those values have been generated. In this case, if the number of concurrent executions for a schedule queue is changed to 120, the number of resident threads for each J2EE server changes to 40 as a result of balancing (120 / 3).
For the case in Figure 3-15, because there are 2 J2EE servers when the number of concurrent executions for a schedule queue is 8, 4 resident threads are generated for each J2EE server.
(3) After the number of concurrent executions changes dynamically (from 5 to 1)
This subsection describes how the system behaves if the number of concurrent executions for a schedule queue is reduced from 5 to 1.
As in the case where the number of concurrent executions increases, when the number of concurrent executions decreases, the number of resident threads that process the requests for each J2EE application also decreases accordingly. In this case, the number of resident threads for each J2EE application is balanced.
However, if the number of concurrent executions for a schedule queue decreases to fewer than the number of J2EE application instances that share the schedule queue, simple balancing causes some J2EE servers to not receive requests. To prevent this, at least one resident thread is generated for each instance.
For the case in Figure 3-15, because there are 2 J2EE servers when the number of concurrent executions is 1, a minimum of 1 resident thread is generated for each J2EE server. Even in this case, however, no more requests than the number of concurrent executions can be processed concurrently. Therefore, the thread for J2EE server 1 does not execute processing until processing with the thread for J2EE server 2 finishes.