Let's look at how the selection mechanism works. As we saw, the mechanism
is used when CICS needs to know if an incoming request should wait for a more
suitable JVM, or when CICS has a queue of requests that do not match a free
JVM, and needs to know if one of them deserves to take, destroy and re-initialize
the JVM. In these situations, the mechanism looks at the complete picture
of the need for different types of JVM in the CICS region. It compares the
demand for, and supply of, JVMs with each profile and execution key, by looking
at:
- The historical data relating to recent requests for each type of JVM (the
demand).
- The number of each type of JVM in the pool, and the time for which tasks
kept these JVMs (the supply).
The selection mechanism uses this data to work out whether a given request
should wait for a JVM of the correct profile and execution key, or whether
it should be given a free JVM. The same answer is valid for a request that
is waiting in a queue for a JVM to become free, or for a request that is made
when there are free JVMs but they are not of the correct profile or execution
key. In both cases, a request is made to wait if the data indicates that the
demand for the type of JVM (that is, a JVM with that profile and execution
key) which the request wants, is generally
lower than
the supply, and so it is not worth destroying and re-creating the free JVM
as a JVM of that type. When the selection mechanism is examining a queue of
requests, it continues down the queue until it reaches a request where the
data indicates that the demand for the type of JVM that the request wants
is generally
higher than the supply. For this request,
the selection mechanism decides that because JVMs of that type are needed
in the CICS region, it is worth destroying and re-creating the free JVM as
a JVM of that type, and assigns the free JVM to the request. If the free JVM
had the wrong profile but the correct execution key, this is a mismatch, and
the JVM is re-initialized. If the free JVM had the wrong execution key, this
is a steal, and both the TCB and JVM are destroyed and re-created. So although
the overhead of re-initializing the JVM, and if necessary re-creating the
TCB, has still been incurred, the selection mechanism has ensured that the
new JVM and TCB are of a type that is likely to be used in the future.
Under certain circumstances, there could be an unusually large number of
requests for JVMs that have been waiting longer than the critical period.
For example, this could happen when a system dump has just been taken, which
delays all processing. In this case, rather than abandon matching and give
each of the waiting requests the next available JVM, as would normally happen
when a request has been waiting longer than the critical period, CICS temporarily
increases the critical period value for the JVM pool. This enables it to perform
matching for the waiting requests, and avoids incurring abnormal overhead.
Once the situation has passed, CICS lowers the critical period value again.