diff options
author | Jon Moss <me@jonathanmoss.me> | 2017-01-04 21:50:15 -0500 |
---|---|---|
committer | Jon Moss <me@jonathanmoss.me> | 2017-03-25 12:44:20 -0400 |
commit | 686f6a762fec59dcda30ed24b12bd9ba9e029d64 (patch) | |
tree | 0d0b0e6b08ee561823b39b6c8b0ea7b8a382604d /guides/source/contributing_to_ruby_on_rails.md | |
parent | d96dde82b7ff3a216c16eb87e2d346341ad53c05 (diff) | |
download | rails-686f6a762fec59dcda30ed24b12bd9ba9e029d64.tar.gz rails-686f6a762fec59dcda30ed24b12bd9ba9e029d64.tar.bz2 rails-686f6a762fec59dcda30ed24b12bd9ba9e029d64.zip |
Action Cable owns database connection, not Active Record
Before this commit, the database connection used in Action Cable's
PostgreSQL adapter was "owned" by `ActiveRecord::Base.connection_pool`.
This meant that if, for example, `#clear_reloadable_connections!` was called on the pool, Active
Record would "steal" the database connection from Action Cable, and
would cause all sorts of issues. This became evident during file
reloads; despite Action Cable trying its hardest to return its borrowed
database connection to Active Record via `@pubsub.shutdown`, Active Record calls
`#clear_reloadable_connections!` on the connection pool, and due to the order of callbacks, Active
Record's callback was being executed first. This meant that if you tried
to rerender a view after a file was reloaded, you would have to wait
through Active Record's timeout and such.
Now, Action Cable takes direct ownership of the database connection it
uses. It removes the connection from the pool to avoid the situation
described above. Action Cable also makes sure to call `#disconnect!` on
the connection when appropriate, to match the previous behavior of
Active Record.
[ Jon Moss & Matthew Draper]
Diffstat (limited to 'guides/source/contributing_to_ruby_on_rails.md')
0 files changed, 0 insertions, 0 deletions