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.
