LEARN. PRACTICE. GROW.1. Define the measurement boundary
Before calculating concurrency, decide what enters and leaves the observed system. In a stable connection-use model, each arrival acquires one connection and each departure releases it. Mean occupancy relates to effective rate and mean holding time: L = λ × W. Forty uses per second lasting 0.2 seconds on average represent eight occupied connections on average. That eight is not a recommended pool maximum. Peaks, variability, waiting, and operational headroom still need analysis. Do not combine the application’s global rate with the duration of an operation only some requests perform. Measures must refer to the same boundary and period.
2. Assess longer holding times
If mean holding time becomes 0.8 seconds, sustaining forty uses per second would require thirty-two occupied connections on average in the model. A pool capped at twenty cannot show thirty-two occupied connections at that instant: the calculation describes demand incompatible with the limit. Queues may grow, throughput may fall, or requests may fail. Investigate the holding-time cause, including dependency waits or excessively long transactions. Increasing the pool without reviewing the backend can shift saturation. Also compare members individually: one pool at twenty of twenty and another empty produce fifty percent overall, but the first JVM is already at its limit.
3. Distinguish queueing, service, and unfinished work
A four-hundred-millisecond mean response can include three hundred milliseconds of queueing and one hundred of service. The user experiences both. If the backend is saturated, doubling application threads can allow more concurrent work without increasing useful completions. Measure arrival rate, departure rate, errors, and time by layer. In a separate sixty-second example, forty-five requests per second arrive and thirty finish, with no losses or cancellations. Unfinished work grows by nine hundred requests. This is count conservation over an interval rather than an assumption of steady state. Use it to explain urgency and admission limits while clearly stating whether measurement includes queueing, execution, or both.
4. Give each phase a time budget
Waiting for a pool connection and waiting for data on an already-acquired JDBC connection are different phases. Reducing only the acquisition timeout does not itself bound an ongoing socket read. Confirm driver, version, and applicable parameter before proposing a change. A report that legitimately receives no data for twenty seconds may fail with a five-second read limit. Subsequent absence of long-running-thread warnings does not demonstrate that the report now works. A local exception also does not prove the final outcome of remote work. Define the overall deadline, phases, recovery, and how operations will be reconciled when their outcome is uncertain.
5. Control attempts and total time
Retries can help with transient failures but add work during persistent failure. In a model with three nested layers and three total attempts at each, one request can generate twenty-seven final calls. The number follows the exercise assumptions; it is not a default WebSphere configuration. In a second model, three two-second attempts and two half-second waits total seven seconds, exceeding a five-second overall deadline. Define where retries are coordinated, which errors qualify, and how idempotency is preserved. Backoff changes attempt timing but does not remove the need for limits and time-budget validation. Always count the initial attempt explicitly.
6. Review capacity before adding members
Three JVMs with pools of twenty-five connections plus twenty reserved for other consumers total a potential of ninety-five. Adding an identical fourth JVM raises potential to one hundred and twenty. If the approved database budget is one hundred, the proposal exceeds it by twenty. This neither measures already-open sessions nor automatically determines performance, but identifies a configuration mismatch requiring a decision. Coordinate application, middleware, and database teams to assess maxima, reserve, and representative load. A capacity experiment should measure useful throughput, errors, queues, and usage with stopping criteria. Complete the change with before-and-after comparison and evidence that the business operation remains correct.
SYNTHETIC MODEL / MODELO SINTÉTICO
40 uses/s * 0.2 s = 8 mean connections
40 uses/s * 0.8 s = 32 required mean connections
3 JVMs * 25 + 20 other = 95 potential connections
4 JVMs * 25 + 20 other = 120 potential connections
3 * 3 * 3 = 27 nested final calls
2 + 2 + 2 + 0.5 + 0.5 = 7 secondsStable model: 40 uses/s × 0.2 s = 8 mean connections. With 0.8 s holding time, the target would require 32. A pool of 20 cannot support that combination in the model.
Common pitfalls
Treating a mean as a safe maximum, hiding a saturated member in the global average, multiplying retries without a budget, or confusing acquisition timeout with JDBC reading.
Related topics: JDBC and transactions · Concurrency and queues · Timeouts and retries
Calculate within the same boundary and period, identify the constraining resource, and validate changes with useful throughput, timings, and business outcomes.
Reference: Statistics and queueing · DR WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30