From 28860d8557663701854e92626b39d8a9207bfca2 Mon Sep 17 00:00:00 2001
From: Cynical Grinch <brand.magnate@gmail.com>
Date: Tue, 21 Feb 2012 11:11:09 +0200
Subject: Added database pooling sub-section to the 'configuring' guide

---
 railties/guides/source/configuring.textile | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

(limited to 'railties/guides/source/configuring.textile')

diff --git a/railties/guides/source/configuring.textile b/railties/guides/source/configuring.textile
index 451235d41d..cd36134e65 100644
--- a/railties/guides/source/configuring.textile
+++ b/railties/guides/source/configuring.textile
@@ -648,3 +648,23 @@ The error occurred while evaluating nil.each
 *+set_routes_reloader+* Configures Action Dispatch to reload the routes file using +ActionDispatch::Callbacks.to_prepare+.
 
 *+disable_dependency_loading+* Disables the automatic dependency loading if the +config.cache_classes+ is set to true and +config.dependency_loading+ is set to false.
+
+h3. Database pooling
+
+Active Record database connections are managed by a connection pool base class called +ActiveRecord::Base.connection+. The class ensures that a connection pool synchronizes the amount of thread access to a limited number of database connections. This limit defaults to 5 connections and is configured in +database.yml+.
+
+Below is an example of the pool limit being set to 25 for a development environment.
+
+<ruby>
+  development:
+    adapter: sqlite3
+    database: db/development.sqlite3
+    pool: 25
+    timeout: 5000
+</ruby>
+
+Since all connection pooling is handled inside of ActiveRecord by default, all application servers (Thin, mongrel, Unicorn etc.) should behave the same. Initially, the database connection pool is empty and it will create additional connections as the demand for them increases, until it reaches the connection pool limit.
+
+Any one request will check out a connection the first time it requires access to the database, after which it will check the connection back in, at the end of the request, meaning that the additional connection slot will be available again for the next request in the queue.
+
+Note: If you have enabled +Rails.threadsafe!+ mode then there could be a chance that several threads may be accessing multiple connections simultaneously. So depending on your current request load, you could very well have multiple threads contending for a limited amount of connections.
-- 
cgit v1.2.3


From 7940976dfd545f7691b63956b067533f9c769339 Mon Sep 17 00:00:00 2001
From: Vijay Dev <vijaydev.cse@gmail.com>
Date: Sat, 25 Feb 2012 21:48:38 +0530
Subject: copy-edits [ci skip]

---
 railties/guides/source/configuring.textile | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

(limited to 'railties/guides/source/configuring.textile')

diff --git a/railties/guides/source/configuring.textile b/railties/guides/source/configuring.textile
index cd36134e65..26292a85f5 100644
--- a/railties/guides/source/configuring.textile
+++ b/railties/guides/source/configuring.textile
@@ -651,20 +651,18 @@ The error occurred while evaluating nil.each
 
 h3. Database pooling
 
-Active Record database connections are managed by a connection pool base class called +ActiveRecord::Base.connection+. The class ensures that a connection pool synchronizes the amount of thread access to a limited number of database connections. This limit defaults to 5 connections and is configured in +database.yml+.
-
-Below is an example of the pool limit being set to 25 for a development environment.
+Active Record database connections are managed by +ActiveRecord::ConnectionAdapters::ConnectionPool+ which ensures that a connection pool synchronizes the amount of thread access to a limited number of database connections. This limit defaults to 5 and can be configured in +database.yml+.
 
 <ruby>
-  development:
-    adapter: sqlite3
-    database: db/development.sqlite3
-    pool: 25
-    timeout: 5000
+development:
+  adapter: sqlite3
+  database: db/development.sqlite3
+  pool: 5
+  timeout: 5000
 </ruby>
 
-Since all connection pooling is handled inside of ActiveRecord by default, all application servers (Thin, mongrel, Unicorn etc.) should behave the same. Initially, the database connection pool is empty and it will create additional connections as the demand for them increases, until it reaches the connection pool limit.
+Since the connection pooling is handled inside of ActiveRecord by default, all application servers (Thin, mongrel, Unicorn etc.) should behave the same. Initially, the database connection pool is empty and it will create additional connections as the demand for them increases, until it reaches the connection pool limit.
 
 Any one request will check out a connection the first time it requires access to the database, after which it will check the connection back in, at the end of the request, meaning that the additional connection slot will be available again for the next request in the queue.
 
-Note: If you have enabled +Rails.threadsafe!+ mode then there could be a chance that several threads may be accessing multiple connections simultaneously. So depending on your current request load, you could very well have multiple threads contending for a limited amount of connections.
+NOTE. If you have enabled +Rails.threadsafe!+ mode then there could be a chance that several threads may be accessing multiple connections simultaneously. So depending on your current request load, you could very well have multiple threads contending for a limited amount of connections.
-- 
cgit v1.2.3

