Hey Session, Did You Forget to Delete Me?

A typ­i­cal rails design pat­tern is to store object ids in ses­sion vari­ables rather than the objects them­selves. Objects can be unwieldy depend­ing on size, com­plex­ity, and asso­ci­a­tions. Ids on the the other hand are small, sleek, and more agile.

So to get an object you do the following.

instance = Object.find(session[:object_id])

Ses­sion data tends to be tem­po­rary. Now if the ses­sion vari­able is noth­ing but a ref­er­ence to an object that is per­sis­tent, say the cur­rent user, then delet­ing the ses­sion object is no big deal. How­ever, if the inten­tion is that the object the vari­able ref­er­ences is also tem­po­rary that could be a prob­lem. Now using the above code to obtain an instance, you can always call

instance.destroy

then just set your ses­sion vari­able to a new value, or nul­lify it (and automag­i­cally remove it from the ses­sion object).

Now here’s where it get’s tricky. What if the user agent does not call the action to man­u­ally destroy the instance? Maybe the per­son behind the browser had to go get a cup of cof­fee. Maybe the coder behind your app—wink, wink, nudge, nudge—didn’t put in the action to man­age tem­po­rary objects. In any case, the ses­sion will expire and your sched­uled cron job will clear the ses­sions duti­fully in the case of PStore or ActiveRe­cord­Store, or will expire out­right in the case of Mem­cached. Unfor­tu­nately, the object to which the ses­sion pointed will linger on (unless of course you add that code to the cron job as well, but that is arguably bad (see below)).

So, what’s the solu­tion? Thanks to a tip from Ruby­Pan­ther on #ruby­on­rails and a bit of Google search­ing, I man­aged to hack some­thing together.

First, setup Rails to store ses­sions in an ActiveRe­cord store. With that you’ll get a ses­sions table. Most of what Rails does with the ses­sions table is hid­den behind the scenes, and you want to keep it that way. This doesn’t mean we can’t stick our hand into the cookie jar. (OK that’s a bad pun.) So next let’s cre­ate a new model.

class Session < ActiveRecord::Base
  # borrowed from lib/action_controller/session/active_record_store.rb
  def marshal(data)   Base64.encode64(Marshal.dump(data)) if data end
  def unmarshal(data) Marshal.load(Base64.decode64(data)) if data end

  def before_destroy
  data = self.unmarshal(self.data)
    if data[:object] then
      object = Object.find(data[:object])
      object.destroy
    end
    true
  end
end

Because the ses­sions table is an ActiveRe­cord store, we can cre­ate an ActiveRe­cord model to get access to it. The mar­shalling func­tions are needed to access the ses­sion data which is noth­ing more than a hash. Then all we need to do is to define the before_destroy call­back to destroy the object that matches the id stored in data[:object]. Now with the fol­low­ing call

s = Session.find(1)
s.destroy

The ses­sion object as well as the object ref­er­enced by session[:object] will be destroyed.

So why the trou­ble of doing this as opposed to just man­ag­ing it in the script file called by the cron job? Well for one thing, your script becomes cleaner.

Sessions.find(:all, :conditions => ["updated_at <= ?", Time.now]).each { |session| 
  session.destroy 
}

Then there’s the argu­ment that how an object is destroyed should be defined in a model def­i­n­i­tion. Plus if the code can be improved to use intro­spec­tion to deter­mine which object to delete based on the hash key, then all the better.

What would be cooler? How about mak­ing a ses­sion object asso­cia­tive? Wouldn’t it be cool to do some­thing like

object.session.create # object.session_id belongs_to :sessions, :dependent => true