While reading the documentation at https://rstudio.github.io/pool/articles/advanced-pool.html, I noticed that it might give the impression that increasing the number of connections in a database pool could help manage "spikes in traffic" (presumably in shiny or plumber applications).
However, since database pools and their underlying connections cannot be shared across process boundaries (e.g., via promise_futures), I am curious about how the intended use-case for database pools was envisioned, aside from the auto-connect feature. As far as I know, database operations (read/write) will always block. One could argue that different connections to the same database could, in theory, be checked out one after another. However, this seems to be an extremely esoteric usage pattern.
I think this information could benetif other (potential) users as well. Thx.
While reading the documentation at https://rstudio.github.io/pool/articles/advanced-pool.html, I noticed that it might give the impression that increasing the number of connections in a database pool could help manage "spikes in traffic" (presumably in shiny or plumber applications).
However, since database pools and their underlying connections cannot be shared across process boundaries (e.g., via promise_futures), I am curious about how the intended use-case for database pools was envisioned, aside from the auto-connect feature. As far as I know, database operations (read/write) will always block. One could argue that different connections to the same database could, in theory, be checked out one after another. However, this seems to be an extremely esoteric usage pattern.
I think this information could benetif other (potential) users as well. Thx.