Thank you, everyone. I really appreciate the detailed answers. On Mon, Mar 13, 2017 at 5:16 PM, Ryan Culpepper <ry...@ccs.neu.edu> wrote:
> On 03/13/2017 03:16 PM, David Storrs wrote: > >> [...] >> On Mon, Mar 13, 2017 at 2:49 PM, George Neuner <gneun...@comcast.net >> <mailto:gneun...@comcast.net>> wrote: >> >>> - 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. >> > > Two threads that share a VC will not have the same real connection *at the > same time*. When a thread uses a VC, it gets an underlying connection > assigned exclusively to it for the lifetime of the thread[*]. When the > thread dies, the VC releases the underlying connection; if it came from a > pool, it returns to the pool and it can be obtained by another thread. > > [*] or until the thread calls disconnect > > [...] >> >> 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? >> > > Yes, but the VC keeps a mapping of threads to connections as I mentioned > above, so it doesn't choose a new real connection per query. > > The connection pool does check that a real connection is still connected > before it hands it out, but there's a race: the server could disconnect > between the check and when the connection actually gets used for the first > time. > > Ryan > > -- 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.
