# Best practice on invoking stale sessions cleanup?

**URL:** <https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242>\
**Category:** Rails\
**Created:** [January 26, 2008, 9:47pm UTC](https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242 "2008-01-26T21:47:04Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![lunaclaire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/f4b2a3/32.png) [@lunaclaire](https://www.ruby-forum.com/u/lunaclaire)\
**Post date:** [January 26, 2008, 9:47pm UTC](https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242/1 "2008-01-26T21:47:04Z")

</div>

I’ve found a few refs to a bit of code to cleanup stale sessions. In  
my ignorance, I’m not sure what the best practice is for invoking this  
process.

Some talk about a cron job, others say to call it from a frequently  
invoked action (e.g. login). This article mentions both:

[http://www.mindsifter.com/2007/1/26/clearing-of-session-data](http://www.mindsifter.com/2007/1/26/clearing-of-session-data)

One comment is that the cron job will cause a load of rails each time  
which could load things too much.

Another is that the calling from the login type of action could also  
cause problems if you’re handling lots of concurrent requests.

What do those of you with experience on fairly active sites say?

---

<div class="post-metadata">

**Author:** ![lunaclaire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/f4b2a3/32.png) [@lunaclaire](https://www.ruby-forum.com/u/lunaclaire)\
**Post date:** [January 26, 2008, 10:15pm UTC](https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242/2 "2008-01-26T22:15:31Z")

</div>

adding to this question…

the bit of code I see everywhere to clear stale sessions is some  
variant of this:

class SessionCleanup  
def self.cleanup  
CGI::Session::ActiveRecordStore::Session.destroy\_all(  
[‘updated\_at \< ?’,  
$session\_cleanup\_interval\_in\_mins.minutes.ago]  
)  
end  
end

nopte that it calls the detroy\_all method…

[ActiveRecord::Base](http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001384) says  
about destroy\_all:

“Destroys the records matching conditions by instantiating each record  
and calling the destroy method. This means at least 2\*N database  
queries to destroy N records, so avoid destroy\_all if you are deleting  
many records. If you want to simply delete records without worrying  
about dependent associations or callbacks, use the much faster  
delete\_all method instead.”

So, again, a best practice question:

Since I don’t think there are dependent associations that would need  
to be destroyed from the session, why not call the delete\_all method  
instead?

---

<div class="post-metadata">

**Author:** ![lunaclaire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/f4b2a3/32.png) [@lunaclaire](https://www.ruby-forum.com/u/lunaclaire)\
**Post date:** [January 26, 2008, 10:59pm UTC](https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242/3 "2008-01-26T22:59:13Z")

</div>

The solution does depend on the particular situation. It is not clear to  
me what you are trying to  
achieve. Is it stale sessions from anonymous visits or ones from account  
logins that forgot to  
logout? Perhaps both.

In the first case, a cron job that runs say once per day will complete  
in like a second or two. I  
don’t see a performance issue here.

For the second case I refer you to a previous post.

[http://groups.google.com/group/rubyonrails-talk/browse\_thread/thread/3bc6b2028346baff#b43d2a0485cd46e4](http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/3bc6b2028346baff#b43d2a0485cd46e4)

I often employ both methods because each addresses a different area.

You are correct, #delete\_all is more efficient than using #destroy\_all.  
Provided that it is  
supported in the context of ActiveRecordStore::Session. I have yet to  
use it so can’t say for sure.

– Long  
[http://FATdrive.tv/wall/trakb/10-Long](http://FATdrive.tv/wall/trakb/10-Long)  
[http://FATdrive.tv/](http://FATdrive.tv/)

----- Original Message -----  
From: “lunaclaire” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
To: “Ruby on Rails: Talk” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Sent: Saturday, January 26, 2008 4:14 PM  
Subject: [Bulk] [Rails] Re: best practice on invoking stale sessions  
cleanup?

---

<div class="post-metadata">

**Author:** ![lunaclaire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/f4b2a3/32.png) [@lunaclaire](https://www.ruby-forum.com/u/lunaclaire)\
**Post date:** [January 30, 2008, 10:08pm UTC](https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242/4 "2008-01-30T22:08:32Z")

</div>

Thanks for the replies and sorry for my delay in responding (other  
matters arose).

I am still on rails 1.2.5, so I cant take advantage of 2.0 goodies  
yet.

I like the idea of going directly to the the DB with SQL rather than  
invoking rails from a cron job.

For the moment I am using the code I posted above and calling it from  
a freq invoked action… works well for now, but I’ll change in  
anticipation of heavier traffic down the road.

---

<div class="post-metadata">

**Author:** ![lunaclaire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/f4b2a3/32.png) [@lunaclaire](https://www.ruby-forum.com/u/lunaclaire)\
**Post date:** [January 27, 2008, 3:26am UTC](https://www.ruby-forum.com/t/best-practice-on-invoking-stale-sessions-cleanup/127242/5 "2008-01-27T03:26:39Z")

</div>

On Jan 26, 2008, at 12:46 PM, lunaclaire wrote:

> One comment is that the cron job will cause a load of rails each time  
> which could load things too much.
> 
> Another is that the calling from the login type of action could also  
> cause problems if you’re handling lots of concurrent requests.
> 
> What do those of you with experience on fairly active sites say?

If you’re using rails 2.0, and the cookie-based session store, you  
don’t have to clear out stale sessions. If you are running an earlier  
version with AR store, you can run a cron job that just runs a mysql  
command to delete records older than a specified age. No reason to get  
Rails involved. If you’re really worried about performance, you can  
nice the command.