Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On 3/13/2017 5:16 PM, Ryan Culpepper wrote: 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

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

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

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On 03/13/2017 04:56 PM, George Neuner wrote: On 3/13/2017 3:41 PM, David Storrs wrote: On Mon, Mar 13, 2017 at 2:04 PM, Ryan Culpepper > wrote: If you are using `prepare` just for speed, it might help to know that most base connections have an

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

Thank you, everyone. I really appreciate the detailed answers. On Mon, Mar 13, 2017 at 5:16 PM, Ryan Culpepper wrote: > On 03/13/2017 03:16 PM, David Storrs wrote: > >> [...] >> On Mon, Mar 13, 2017 at 2:49 PM, George Neuner >

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On 03/13/2017 03:16 PM, David Storrs wrote: [...] On Mon, Mar 13, 2017 at 2:49 PM, George Neuner > 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

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On 3/13/2017 3:41 PM, David Storrs wrote: On Mon, Mar 13, 2017 at 2:04 PM, Ryan Culpepper > wrote: If you are using `prepare` just for speed, it might help to know that most base connections have an internal statement cache that maps SQL strings to

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On Mon, Mar 13, 2017 at 2:04 PM, Ryan Culpepper wrote: > On 03/13/2017 12:49 PM, David Storrs wrote: > >> [...] >> >> >> Assuming I've understood all that correctly, my last question would be >> how to get around the 'can't do prepare with a virtual connection' issue >> for

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On Mon, Mar 13, 2017 at 2:49 PM, George Neuner 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,

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

Hi David, On 3/13/2017 12:49 PM, David Storrs wrote: I've got a centralized database connector: (define dbh (virtual-connection (connection-pool (thunk (postgresl-connect ...) This gets passed around from handle to handle and into various temporary or

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

On 03/13/2017 12:49 PM, David Storrs wrote: [...] Assuming I've understood all that correctly, my last question would be how to get around the 'can't do prepare with a virtual connection' issue for situations where I've been passed a connection (perhaps from third party code) and it might or

[racket-users] Virtual connections, threads, and DSN extraction, oh my!

I've got a centralized database connector: (define dbh (virtual-connection (connection-pool (thunk (postgresl-connect ...) This gets passed around from handle to handle and into various temporary or ongoing worker threads. Thinking about it, I'd