In this twelfth part of a multi-part series on the Action Pack library for Rails, we'll focus on the architecture of Rails and how the system handles session data. This article is excerpted from chapter six of the book Beginning Rails: From Novice to Professional, written by Jeffery Allan Hardy, Cloves Carneiro Jr. and Hampton Catlin (Apress; ISBN: 1590596862).
Action Pack Sessions and Architecture (Page 1 of 2 )
The Shared-Nothing Architecture
Rails is built on the principle of a shared-nothing architecture. When we say shared-nothing, we mean that no piece of data is shared between the servers that host the application. Storing session data on the server would violate this principal.
Imagine that you were storing your session data on the file system of the server that runs your application. This would work fine as long as you were using only one server for your application. But what happens when your site becomes busy and you decide that you need multiple servers to keep up with the traffic? You would need to use a load bal-ancer—a hardware or software layer that routes requests to one of several application servers to spread out the load. Say a request comes in to server 1, and you store some session data in the file system. Then server 1 gets busy, and the load balancer decides to send the next request to server 2. But the session data isn’t on server 2; it’s on server 1. This presents a dilemma. The shared-nothing architecture avoids this problem by keeping the state somewhere other than on the application server, like the database, as shown in Figure 6-4.
Note David Heinemeier Hansson (the creator of Rails) has written about his thoughts on the shared-nothing architecture on his blog at http://loudthinking.com/arc/000479.html .
Note Purists will argue that this isn’t really shared-nothing. After all, we’re sharing the database server. But since a single database server can service dozens of application servers without a hitch, using it as a centralized storage location for session data is a worthy compromise.
Storing Sessions in the Database
The default file system session storage mechanism will “just work” with no configuration required. However, we feel that storing session data in the database is important enough that it’s worth taking a brief detour to set up. Fortunately, Rails makes this an easy affair. There’s a built-in Rake task called db:sessions:create that will make a migration to create the sessions table. To run it, enter the following from your application’s directory on the command line:
This will create a migration to create the necessary sessions table in the database. All we need to do is run it.
$ rake db:migrate
Now that the sessions table has been created, we need to tell Rails that we want to use the database for session storage. This is matter of configuration, and is therefore specified in the config/environment.rb file. Open this file in your editor and you’ll see the session configuration options are already there, though they’re commented out.
# Use the database for sessions instead of the file system # (create the session table with 'rake db:sessions:create') # config.action_controller.session_store = :active_record_store
Remove the comment from the last line to activate the active_record_store option for sessions, as shown in Listing 6-13.
Listing 6-13. Activating active_record_store in config/environment.rb
# Use the database for sessions instead of the file system # (create the session table with 'rake db:sessions:create') config.action_controller.session_store = :active_record_store
You’ll need to start and stop your web server for this change to take effect. Remember to use Ctrl+C to stop the server (and ./script/server to start it up again).