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.

Reply via email to