Skip to content
Browse files

Revert "updates the new default pool size in some additional places"

Reason: We are about to temporarily revert the change to the default.

This reverts commit 5c0aba2.
  • Loading branch information...
1 parent a149612 commit 73324fd830723022178fe87e42e081442846145b @fxn fxn committed Mar 7, 2012
View
4 railties/guides/source/command_line.textile
@@ -521,9 +521,7 @@ development:
adapter: postgresql
encoding: unicode
database: gitapp_development
- # Maximum number of database connections available per process. Please
- # increase this number in multithreaded applications.
- pool: 1
+ pool: 5
username: gitapp
password:
...
View
8 railties/guides/source/configuring.textile
@@ -652,19 +652,17 @@ The error occurred while evaluating nil.each
h3. Database pooling
-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 1 and can be configured in +database.yml+.
+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
- # Maximum number of database connections available per process. Please
- # increase this number in multithreaded applications.
- pool: 1
+ pool: 5
timeout: 5000
</ruby>
-Since the connection pooling is handled inside of Active Record 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.
View
12 railties/guides/source/getting_started.textile
@@ -329,9 +329,7 @@ environment:
development:
adapter: sqlite3
database: db/development.sqlite3
- # Maximum number of database connections available per process. Please
- # increase this number in multithreaded applications.
- pool: 1
+ pool: 5
timeout: 5000
</yaml>
@@ -352,9 +350,7 @@ development:
adapter: mysql2
encoding: utf8
database: blog_development
- # Maximum number of database connections available per process. Please
- # increase this number in multithreaded applications.
- pool: 1
+ pool: 5
username: root
password:
socket: /tmp/mysql.sock
@@ -374,9 +370,7 @@ development:
adapter: postgresql
encoding: unicode
database: blog_development
- # Maximum number of database connections available per process. Please
- # increase this number in multithreaded applications.
- pool: 1
+ pool: 5
username: blog
password:
</yaml>

0 comments on commit 73324fd

Please sign in to comment.
Something went wrong with that request. Please try again.