Blocking-wait versus fail-fast: Neo4j Java driver pool exhaustion under high concurrency

Goal: Identify the connection pool exhaustion strategy that best balances transaction latency and error visibility for Neo4j Java driver workloads with bursty concurrency.

Constraint: The driver uses a fixed pool size of 50 by default and blocks threads for up to 30 seconds (default timeout) before throwing a TransientException when the pool is full; no built-in back-pressure or adaptive sizing is provided.

Uncertainty: Whether a blocking-wait approach, which defers failures to preserve in-flight work, or a fail-fast approach, which rejects new requests immediately, better suits operational goals under varying transaction durations and concurrent request patterns.

Questions: What trade-offs exist between latency sensitivity and error predictability when choosing between blocking-wait and fail-fast pool exhaustion strategies? How does pool size interact with typical transaction duration and concurrent request patterns in production workloads? Can observed transient failure rates be reliably attributed to pool exhaustion versus underlying query performance?