James,

Thanks for the comments. I am coming from a Smalltalk background and we
would typically cache code/description lookup table rows into a class
variable for performance. That is, when we wanted to look up a
description we would check the cache first and then hit the database
only if it had not been retrieved yet.

In this scenario, it's not a problem if the cache is maintained
individually over separate instances of the interpreter. This way every
user benefits from the cache rather than storing it in a session unless
I misunderstand the life cycle of class variables. I would think they
would live until the class is reloaded.

However, I do see your point and agree and that under most application
situations this would not be the way to go.

Thanks,
Paul


James Edward Gray II wrote:
> On Aug 18, 2006, at 9:05 PM, Paul wrote:
>
> > To keep rails from reloading the class every time you
> > can change the ..\config\environments\development.rd file.
>
> You really, really don't want to do this.  Trust me.  ;)
>
> You've already noted that this makes development mode suck.  If you
> go this way, you will need to toggle the setting every time you need
> it to work or go without Rails's best development feature.  Ouch.
>
> That should be reason enough, but it gets worse!
>
> Depending on how you deploy your application, it's quite likely you
> could have two or more separate interpreters running your production
> code.  These will *not* share class variables.  This is the way of
> pain and could be a source of all kinds of nasty issues.
>
> If you need to remember a value in Rails it needs to be in the
> database or the session.
> 
> James Edward Gray II