In a recent large Rails project I’ve been developing, I had an elusive error: some views that I was rendering contained the wrong data. It escaped testing - the unit, integration and functional tests all were green - but every once in a while bad data would come up. Once a day, more or less, I’d be looking at an impossible page. After too much investigation I identified the problem: it turned out to be a piece of data being held in the session was getting modified by two relatively independent parts of the application. It wasn’t being done intentionally - it was just by coincidence that I’d used the same name for two different pieces of data.
While this is not a big deal for small applications, in large projects or ones in which multiple developers are working on different parts of the code, the potential for namespace collisions in the session can become significant. And when that happens, finding the problem can be painful. And unfortunately, the remedy may be a challenge - how to obtain an unused symbol that doesn’t overlap with anything else already in use.
Rails took on the problem of namespace collision in Controllers and Views early on (See the section on Grouping Controllers into Modules in Agile Development with Rails by Dave Thomas and David Heinemeir Hansson) but there was no relief given for sessions. This may be by design. The intention is that persistent state should be stored in the database, however this state is somewhere between persistent and volatile. As I’ve developed web apps that act more like standalone apps, session state is required.
What I’ve done is built virtually invisible session context switching into my rails apps with a mechanism that is only noticeable when crossing contextual boundaries. This is now generalized into a nice clean mechanism which is described as the Context Problem.
The Context Problem in the Rails Session
Say I’ve written a
FooController that refers to a session variable as
A few weeks later I get a request from a client who needs some
Bar views which I create and back with a
Because I didn’t have to think too much when I was creating the part of the app that worked with
Foo, I forgot that I used
session[:mumble], and inadvertently used it again in
Unaccountably, the tests run fine, as the two parts are relatively unrelated and the contexts don’t happen to cross in the tests cases. But the error is lurking and there’s no good way to find it short of more testing or through a series of exhaustive code reviews. And neither is a guarantee. Adding more tests may not necessarily find the overlap. As the size of the application increases, the number of tests needed to identify such situations may grow disproportionately, and the problem may still not be found. Code reviews may help, but if the code base is large (yes, we are talking about Rails-in-the-Large here) the system probably gets reviewed in contextually-related chunks, clearly missing the problem again.
Couldn’t it be attacked through automation? Sometimes it can - a scan could reveal session keys that are the same in different parts of the code. But given the dynamism that makes Ruby so great, the keys may be computed, or the code that is messing with the session may be generated through metaprogramming. Then the namespace collision won’t happen until it’s released in the field and it’ll probably be at your biggest customer in the middle of the night. Of course.
The issue isn’t how to find and fix such problems when they occur, but how to avoid the problem entirely.
Brute Force and Blunt Trauma
The problem can be solved entirely via discipline - at least for those who are disciplined. By prefixing the context onto the symbol, there’s no longer an overlap:
That works well but it’s easy to forget and painful to type. If you have long context names it’s even more painful. Just think of all the typos. And if the code is generated, the mechanisms needed to add context everywhere need to be put into place. You would always need to be very disciplined.
It’s fragile, but it does work. An advantage of this method is that it’s readily clear what the context of a session variable is just by looking at it. But it definitely isn’t the Rails way. More typing means there’s probably a better way to do it. But first, we’ll consider the issue of discarding old state.
Interestingly, in cognitive science (in a sense, applications are but a mechanization of cognitive science) the hardest thing to do is to carefully forget information. The effort needed to remember things in a coordinated way is almost trivial in comparison with that of forgetting. Getting rid of integrated information is hard. Especially when we need to be selective about what values we must forget and make sure that losing the information at the wrong time doesn’t make a mess.
If we use the simplest scenario, our controllers are adapted to cleanse themselves completely on demand by erasing the session variables that start with their prefix:
This certainly seems ripe for a little refactoring.
If the methods are lifted and we put some smarts into the
Now a sending
"bar" to the cleanse method will nil-out the session context whose variables start with
Unfortunately, it will also clean out state starting with
"bar_room_brawl_" - and in the same way, we can still get into the same problem of context overlap.
So though this may or may not be a good solution for you, it wasn’t enough for me.
A Better Session
Let us go back to basics. A session is a hash that holds state. For our purposes, context is a partitioning of session. If we consider contexts to be disjoint (non-overlapping) then a context is also a hash that holds state. We want to store our state in the context hashes rather than in the session hash.
This is all great, but there’s an awful lot of Rails code that already references session and, while I love to refactor, I hate changing lots of stuff. And since the session hash is the predominate state storage mechanism, with lots of code written for different back-end session storage already, whatever needs to be done has to piggyback on what’s already there.
The trick is to build context hashes in the session hash as needed, and do a little dance to pull up the right context when a session is requested. Whatever the mechanism, it needs to be virtually invisible, be able to be expanded for all sorts of uses, and it needs to work without requiring changes to existing Rails code, at least for simple controllers that don’t cross context.
So let’s let contexts be hashes, and for consistency’s sake we’ll call them
We’ll access a
subsession in the same way as session in Rails, as a key-value hash.
What’s more, we’ll change the accessor to session into
supersession, and on demand, return the
subsession context when the session accessor is requested.
Of course, a
subsession has to come into existence at the right time.
They need to overlay the session in
ActionController::Base and be available to all of our controllers.
It makes sense to put the methods into the
By using a
before_filter, it can do our
subsession creation or access each time a controller is created to service a request, all behind the scenes.
What’s more, other contexts can piggyback on the
subsessions scheme just by utilizing the context creation and access mechanisms.
We also need to be able to forget - we have to be able to cleanse contexts as needed.
So we create a cleansing method that, given a context identifier, removes the
However, it’d also be nice to purge a whole lot of
subsessions using a single key.
The way to do this is to store the set of contexts identifiers in the
supersession, each with an associated key that can be the same for multiple contexts.
cleanse method can purge a single context, or purge multiple contexts based on a test of the associated key.
Having the context list is also nice for investigative purposes, possibly providing important clues when things have gone wrong.
Finally, since we need to be able to make and access contexts, we need to decide on what basis context can be identified.
We’ll do what makes sense and is as versatile as possible.
If we’re supplied a symbol, that’s a great accessor.
If we’re given a string, we turn it into a symbol.
If we’re given a
Module, use the symbol corresponding to its name.
And if we’re given an instance of an object, we assume its class’ name.
We make two more shortcuts when accessing the session - one to provide a way to get the current
subsession, and the other to get the
All the mechanics are there, and context is created for controller and is accessed by
session as if nothing happened.
…that is unless we have to break out of our context.
Happily, this is just a logical change to the way we access a
Simple web applications won’t need much of this, as crossing contextual boundaries isn’t typical. But when Rails projects get large, as mine have begun to, maintaining disjoint contexts and being explicit about boundaries will save me a lot of sleep. And since it pretty much works invisibly, I can rest even easier.