Long story short: Ruby on Rails session handling does have some concurrency problems. Especially with AJAX requests this is a very potential scenario:

1. Request 1 loads user session
2. Request 2 loads user session
3. Request 1 stores something to the session
4. Request 2 stores something to the session
5. Request 1 writes its session data to the database
6. Request 2 writes its session data to the database

Now, of course whatever request 1 wrote there is pretty much lost. These bugs are hard to find, and in my case the site had been in production use for 18 months before this really became a problem.

I soon found out that Frederick Cheung had already written a plugin called Smart Session Store to handle these race conditions by locking the session row when needed. However, it didn’t work with the latest PostgreSQL drivers.

I’ve fixed this to work with combinations of the pg/postgers driver and Rails 2.2/2.3 in my smart_session_store fork. The tests are also now actually testing something. I’ve sent a pull request, so everyone should be able to enjoy it soon.

It’s really a good practice to somehow handle session concurrency even before it’s a problem, because these kinds of bugs tend to appear when you least expect it.

We can test this by adding two actions to our controller. They should both write something to the session, and the other one should sleep a while to make sure that its changes are likely to be lost.

The Firefox plugin, Ubiquity, is an awesome extendable Swiss knife command line of the web. The other day I noticed that Jack Dempsey had written a Ubiquity command for searching the Ruby documentation from APIdock. After quick googling, I found out that different people had done the same for Rails and RSpec as well, based on Jack’s command. Talk about community effort! Here are links to the Ubiquity commands (you need to have Ubiquity installed):

• Rails
• Ruby
• RSpec

APIdock 1.4 (IRON STEVE) was deployed a few minutes ago. The release consists of mostly bug fixes and some minor stuff.

The docs for the new Ruby on Rails 2.3.2 with Rack and Metal and all kinds of other awesomeness are being imported as I’m writing this. Check the new docs here.

Update: RSpec 1.2 was just imported as well. To the docs

I must not be the only one who occasionally wants to stop a Ruby on Rails application. There are long-running and risky database schema migrations and data migrations, and you don’t want users fiddling the system in the middle of the deployment.

With a Mongrel-based setup it was easy to set up a 503 (Service unavailable) error page and then just shut down all the Mongrels, so that Apache could give users a maintenance page. Using mod_rails (Phusion Passenger), only restart is supported out-of-the-box.

However, it’s possible to use mod_rewrite to prevent users from accessing your site during the deployment. Try this in your Apache virtual host configuration file:

# This option is not needed with Passenger >=2.1.1.
RailsAllowModRewrite on

ErrorDocument 503 /503.html

RewriteEngine on

RewriteCond %{DOCUMENT_ROOT}/../tmp/stop.txt -f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /$1 [R=503,L]

Basically the last three lines mean:

1. If there is a tmp/stop.txt file
2. and user is requesting a file that does not directly exist in the file system
3. then return error 503 and render the appropriate maintenance page

It doesn’t actually stop your Rails processes, though. They will die when Passenger times out.

Now it’s also easy to incorporate this to your Capistrano configuration:

namespace :passenger do
  desc "Restart Passenger"
  task :restart, :roles => :app do
    run "touch #{current_path}/tmp/restart.txt"
  end

  desc "Stop Passenger"
  task :stop, :roles => :app do
    run "touch #{current_path}/tmp/stop.txt"
  end

  desc "Start (or un-stop) Passenger"
  task :start, :roles => :app do
    run "rm -f #{current_path}/tmp/stop.txt"
  end
end

After this it’s safe to deploy big new releases without completely taking down your Apache.

In addition to all kinds of general Ruby fame, Dr. Nic is the creator and maintainer of the Ruby on Rails Textmate bundle. Now, it seems that just a few hours ago he noticed that our Ville Lautanala aka Lautis had written a few good bugfixes and changes to the bundle. He then went ahead and merged them to the master branch.  And the real kicker here is, that among those changes was the change that adds APIdock-powered documentation macros. Let’s hope that this change sticks so all Rails codin’ Textmate users will be able to enjoy the rich documentation browsing that APIdock provides.

Will the Ruby bundle, which is also maintained by Dr. Nic, follow next?

Update: Origin of the bundle can be changed using following commands:

% cd ~/Library/Application\ Support/Textmate/Bundles/Ruby\ On\ Rails.tmbundle
% git remote rm origin
% git remote add -f -t master -m master origin git://github.com/drnic/ruby-on-rails-tmbundle.git