On Monday, 5 October 2015 14:37:56 UTC+11, Michael Vigilante wrote:
> This is also an excellent point; I wasn't aware this was the case. It
> certainly feels like a waste to be doing this every time a database
> operation is run. I'm not sure what an appropriate level of alive
On Friday, 2 October 2015 05:28:01 UTC+10, Matt jones wrote:
>
>
> With per-DB-interaction checkin/checkout, it doesn't appear to be possible
> to reliably manipulate these variables, as the connection used in the first
> statement may not match the one used in the second. More amusing /
>
>
> On Thursday, 1 October 2015 03:30:55 UTC+10, Xavier Noria wrote:
>
> Transactions are per connection, how does that approach handle them?
>
>From what I can tell, ActiveRecord only provides one way to manually open a
transaction, which is a `transaction do ... end` block; in this case, if
OK, mock-up is here:
https://github.com/stranger-zedd/activerecord-connection-pool-tests
On Tuesday, 29 September 2015 08:37:43 UTC+10, Michael Vigilante wrote:
>
> On Tuesday, 29 September 2015 00:46:14 UTC+10, Aaron Patterson wrote:
>>
>> I don't really follow. If you have
On Tuesday, 29 September 2015 00:46:14 UTC+10, Aaron Patterson wrote:
>
> I don't really follow. If you have 5 request threads, and 5 connections
> available, no request thread will contend on a lock for a connection
> (unless you are using threads, which means you'd have 1 + new
>
On Sunday, 27 September 2015 06:54:16 UTC+10, Aaron Patterson wrote:
> Is it counter-intuitive? If you're doing database intensive work, then
> you'd probably want the same number of connections as you have request
> threads in order to maximize throughput, otherwise you'll still be
> blocking
Hi, just a small question on the way connections are managed in
ActiveRecord.
>From the best I can gather reading the code (and based on behaviour),
ActiveRecord will check a connection out of the pool the first time a
thread asks for one, then that thread will continue to hang on to the
