Storing sessions in a cache is a really bad idea. Too many sessions, and they start expiring randomly. I have been bitten by this, so I always store sessions in a non-lossy data store now. (BerekelyDB, FWIW.)
(As for in-cookie sessions, I like the idea, but it does require some server-side state to allow a user to invalidate his previous sessions. If someone steals the cookie, they have access to the system "forever", and the user has no recourse. The solution is to store a serial number in the user object, and reject sessions less than the current number, but I don't think Rails implements it this way by default.)
I am also not a big fan of running the cleanup job from cron. My main application has an event loop capable of firing timers (libev), so I use that to kick off a (forked) cleaning process. That requires no additional configuration on the system that the app is running on, which is just the way I like it. (Yeah, I know I am reinventing UNIX. UNIX needs to be reinvented.)
The event loop has other advantages, like non-blocking IO, and non-blocking subprocess invocations. A request can literally wait all day for a database query, and it won't prevent the app process from handling other requests.
I've never had this issue, so I'm either using a bigger cache than you, or I'm storing less in the session.
>. Cookie store
I can't really speak to why the rails core team made this default, I think it's a step backwards.
> libevet...
That's certainly an option too. The beauty of this tool though isn't in the ruby syntax for cron. It's in using capistrano deployment flexibility and expressiveness for managing distributed crontabs.
I can't really speak to why the rails core team made this default, I think it's a step backwards.
"It's cool." Seriously though, they probably picked it because it requires no configuration. It also avoids hitting the database for things like "Logged in as jrockway", which is always a good thing.
(As for in-cookie sessions, I like the idea, but it does require some server-side state to allow a user to invalidate his previous sessions. If someone steals the cookie, they have access to the system "forever", and the user has no recourse. The solution is to store a serial number in the user object, and reject sessions less than the current number, but I don't think Rails implements it this way by default.)
I am also not a big fan of running the cleanup job from cron. My main application has an event loop capable of firing timers (libev), so I use that to kick off a (forked) cleaning process. That requires no additional configuration on the system that the app is running on, which is just the way I like it. (Yeah, I know I am reinventing UNIX. UNIX needs to be reinvented.)
The event loop has other advantages, like non-blocking IO, and non-blocking subprocess invocations. A request can literally wait all day for a database query, and it won't prevent the app process from handling other requests.