In Ruby on Rails how can I persist objects in memory between sessions

Question

I'm trying to build something (ultimately a gem but for now an application) that works as follows.

Suppose for example the DB records are breeds of dog. There's a Dog parent class and a child class for each breed. The actual breeds aren't known until runtime.

When the server begins it will load up records from the DB and instantiate instances of classes based on the records, e.g. I may have two beagles and poodle. When someone comes to the server they may want to access one of those dog instances.

Why not just create the instance on the fly? In my case the "dogs" are basically classes that hold an algorithm and data. The algorithm doesn't change, the data changes rarely (on the order of days), but the execution of the algorithm itself, which uses both data and some dynamic data passed in such as a timestamp, will be accessed multiple times a second.

It would be silly to have to recreate an instance of the object and load the data each time just to do a request only to do it again on the next request (the requests don't change the state of the object). I'd be creating and destroying multiple objects a second when I could just reuse the same object.

it doesn't make sense to keep it in the session, since someone wanting a poodle shouldn't need to have the beagles information in her session object; it's irrelevant (and doesn't scale).

How do I persist these objects in memory? I basically want a lookup table to hold the instances. In Java I would create a singleton with some type of hashmap or array that sits in memory. In rails I tried this by creating a singleton class in the lib folder. I think--I may not be understanding this right--that the instance (the fact that it's a singleton is moot) is being lost when the session disappears.

The closest answer I found was http://www.ruby-forum.com/topic/129372 which basically puts everything in class fields and methods. Somehow that doesn't seem right.

TIA!

Addition: I come from Java. In Java I'd just create an object that sits on the heap or maybe in a JNDI tree and as HTTP requests came in they'd be handled by a a servlet or EJB or some per-request item which could then access the persistent object. I can't seem to find the equivalent in rails.

Answer 1

Maybe your example is confusing in its simplicity. I assume your objects are quite complicated and that your benchmarking shows that constructing them is unreasonable to be done on each request.

In production mode, classes are not unloaded between requests, but instances of those classes are. So using class members of a class sounds like the way to go to me. Just use it to store your instances.

class ObjectCache
  @@objects = {:beagle => Beagle.new, :poodle => Poodle.new}

  def lookup key
    @@objects[key.to_sym]
  end
end

Answer 2

I wouldn't worry too much about loading and discarding objects unless you can come up with a benchmark that proves it's an issue. Each request creates an extraordinary amount of intermediate objects as a matter of course, and these are generally created and destroyed in a matter of several milliseconds.

It's generally better to focus on loading only what is required, de-normalizing your database to push frequently accessed data or methods into a convenient location, or saving the results of complicated calculations in a cache field.

Benchmark first, optimize only when required.

Saving instances of models to a class cache can work, but it is only an option in a production environment where the model classes are not reloaded with each request. It can also expose you to errors caused by stale data.

If you have a scaling problem that cannot be solved with these methods, you might want to investigate building a persistent server for a portion of your functionality using a combination of Rack and EventMachine. There are a number of ways to go about building a background process that can perform complicated calculations using a pre-loaded set of data, but the specific approach will depend on several things such as the type of data you're working with and how frequently it will be accessed.