The only time I've seen one connection per thread being an issue was in one
app that ran many processes and it started to reach the connection limit of
their db server in traffic peaks. Even in that scenario, contention is also
a risk if you reduce the pool.
Other than the mental image that you're using less resources (at the price
of contention), I am not sure there is going to be any significant
practical win. It could be, I am not saying it wouldn't (I have not done
your study), but at first sight the cost/benefit is not clear to me in
practical terms.
Regarding transactions, #execute is public AR interface, and
AR::Base.connection.execute('START TRANSACTION')
is valid AR code, I am not sure if drivers know the connection is in a
transaction and have API to check, but #transaction_open? returns false as
of this writing. Why would anybody do that? I don't know, maybe because
they are writing a heavy SQL oriented script and doing that manually feels
natural... it doesn't matter, it can be done.
Another practical point is that when a connection is checked out the
connection pool tests if it is alive issuing for example SELECT 1. That
would mean that if a request performs today 200 queries, they would become
400 queries. I don't know if the alive check could be rethought to run less
frequently, but it probably should to avoid that 2x.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
