When you do something like connection.execute()
, that work will handled by a worker thread until the call completes. And each underlaying Oracle connection can only ever do one 'thing' (like execute, or fetch LOB data) at a time. This is why you want the number of worker threads to be at least as big as the number of connections in the connection pool. This allows connections to do their thing without blocking any other connection. And this is why Promise.all()
using a single connection is bad - because each of the 'parallel' operations can use a thread but will be blocked waiting for prior work on the connection to complete. Work on a single connection can only ever be serial, not parallel. Using Promise.all()
where each unit of work has its own connection is OK, but is rare.
Check the node-oracledb documentation Connections, Threads, and Parallelism and Connection Pool Sizing.
Node-oracledb will queue connection pool requests (e.g. pool.getConnection()
) if every connection in the pool is already in use. This provides some resiliency under connection spikes. There are some limits to help real storms: queueMax
and queueTimeout
. Yes, at peak periods you might need to increase the poolMax
value. You can check the pool statistics to see pool behavior. You don't want to make the pool too big - see the doc.
Side note: process.env.UV_THREADPOOL_SIZE
doesn't have an effect in Node.js on Windows; the UV_THREADPOOL_SIZE
variable must be set before Node.js is started.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…