On 3/13/2017 3:16 PM, David Storrs wrote:
... you talk about the "real connection", singular -- aren't there
multiple real connections underlying the pool?
Yes, a pool maintains some number of real connections to the DBMS.
Note, however, that a pool can be configured to maintain just a single
connection:
(connection-pool ... #:max-connections 1 #:max-idle-connections 1)
- The pool will maintain some number (hopefully >0) of real
connections. Every time the virtual connection receives a request,
that request will be forwarded to a real connections, creating the
connection if necessary. (Presumably either the pool or the VC will
take responsibility for verifying that the connection in question has
not been disconnected by the RDBMS and generating a new one if it has.)
Is that right?
Yes. In either case, new DBMS connections will be created on demand if
needed.
However, a virtual connection effectively opens and closes a real
connection for EVERY query. This will be the actual behavior if the VC
is created using a connect function. You really need to use a pool if
actual DBMS connections are slow to establish.
The default open/close behavior generally is OK for a local database
solution - e.g., Sqlite, or a DBMS server co-resident with your program
on the same host. But even with a co-resident DBMS server, it will work
better if you can use Unix sockets rather than [loopback] TCP.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
