Authlogic session model naming

Just a quick note on Authlogic and naming of the User and Session models.

Generally most people I assume use the name User for the user model and UserSession for the session information. I had this working and then decided the session information would be better described by the name LoginSession instead so went about renaming all the relevent classes/methods etc.

After this change Rails would return an error message of uninitialized constant Login whenever I tried hitting the login page. This is due to Authlogic’s default behaviour of  inferring the user class name from the session model name, in this case, Login from LoginSession.

To get around this use authenticate_with <classname> within your session model to tell Authlogic to authenticate against a different user model. i.e

authenticate_with User

Hopefully this will save someone else the time I spent working out why my app had broken through a simple name change.

Ruby On Rails running threads & MySQL silently stops updating after 5 transactions

In my current Ruby n Rails project, the focus of work is to periodically update database entries from XML feeds.

Naturally I’ve implemented a threading system using the rufus-scheduler gem for updating database entries every so many minutes. However I soon noticed that after running on the development enviroment with 1 minute intervals on updates, that the updating of the last updated time column in the db suddenly stopped after about 5 iterations. No error, warnings or other signals (smoke or otherwise).

After a bit of head scratching I finally managed to mentally link the 5 iterations to the pool number setting in the database.yml file. Executing my database updates within the thread job was stopping Rails from cleaning up the unrequired connections (for whatever reason. I suspect this is because the thread is sent back to sleep before this can occur).

So the solution is to simply call the cleanup manually via…

ActiveRecord::Base.connection_pool.clear_stale_cached_connections!

… at the end of every job execution run. Problem sorted!