On Mon, Mar 13, 2017 at 2:49 PM, George Neuner <gneun...@comcast.net> wrote:
> > This is why you can't use prepared queries with virtual connections - > because there is no guarantee that the connection that prepared the query > will be the same one that tries to execute it. > *nod* Good, that's what I thought. Nice to have it confirmed. > > > - The connection pool (CP) inside the VC will maintain a (small?) > collection of persistent connections to hand out upon request, so I'm not > paying the connection-setup-time penalty every time I use it. > > > Yes and no. The pool will try to keep idle connections, but the DBMS > eventually will close them (subject to the keep-alive settings in > postgresql.conf). > Ah, makes sense. Still, the point is that in the normal case events I shouldn't need to pay the setup cost each time. > > - It's also fine to pass the VC into other threads. It will be shared > state between the threads, but the CP will keep their connections isolated > and when the threads terminate it won't interfere. (Ignore pathological > cases -- obviously if I give it to enough threads and they all use it at > once then we might exceed the DB limits on number of handles, speed, > bandwidth, etc.) > > > No. A VC is not tied to any particular real connection, so it's not > possible to guarantee that 2 threads sharing a VC do not share an RC. > It's actually quite likely in a lightly loaded system. > > If you need connection isolation, you have to use real connections. > Gotcha. Thanks. > Real connections will persist until closed. Virtual connections can come > and go like dreams. > If this were a forum I would sig that. :> > There is no way in the current implementation to get at the real > connection underlying the virtual one. Because the system multiplexes > connections, I think it probably would break badly if you were able to > somehow get hold of the underlying real connection. > > > I know this isn't what you want to hear. > George > Hey, I'd rather hear uncomfortable truth than comforting lies. Still, in the above you talk about the "real connection", singular -- aren't there multiple real connections underlying the pool? My mental model for how this works is: - User creates a function F that creates real connections - User hands F to a pool via: (virtual-connection (connection-pool F)) and gets back a VC. - 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? > -- > 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. > -- 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.
