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.


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.

Reply via email to