and that did not work. It is as if rails
completely unloads the controller between invocations.
In development mode, it does. And in production, there's no guarantee
that you'll get the same server instance as last time, so you can't
really rely on class variables in the controller. You might be able to
rig up something in a model...
But this smells funny. What exactly are you trying to do here? In most
cases, if data is worth saving, it's worth putting in the DB.
Thanks for your reply. Here is what I am trying to do...
We are trying to use mongrel as a job execution engine and use rails for
the front end GUI. We intend to have an initial configuration screen
where the administrator will populate various properties in form for use
in determine how the various jobs will run. Whenever the 'system' (and
system will consist of more than, but include, mongrel) is brought down
for maintenance we want the admins to reexamine these properties so we
want them 'forgotten' between maintenance windows. Scalability is not
an issue here as only a handful of admins will use the tool, (thus no
clustering will be involved) and I expect statics will work. In fact,
when I moved the TransientData class to a file called library.pl in the
lib directory and required it in the controller it did (finally) work.
If the right approach is to use an active record, despite the lack of
need for persistence, can one create an active record and declare it to
be a singleton (i.e. never more than one row in the database)? Can one
do the equivalent of a j2ee startup bean and have a mongrel run a job
upon startup of the server so I could delete that singleton? The idea
of being able to use an active record and have all of the validation
goodies does appeal to me.
I intend to spin off worker threads(or fork if need be) after the
initial 'submit' button is pushed.
Those workers will tend to the jobs at hand.
Yes I meant library.rb (not perl)...
I really do not want to use a yaml file. Some of the config data will
include passwords to other systems that the worker threads will need to
perform their duties. Also, the admins will get cranky if I make them
modify a yaml file.
If I use a 'singleton' active record I do need to figure out how to
encrypt the password in the database.
If I use a static, err class variable, I am more than willing to roll
the dice and assume no one will dump mongrel's memory and hunt for it.
I am very willing to use the class variable approach, but I am highly
curious how to build a 'singleton' model to make use of the various
active record goodies (assuming I can delete it upon startup).
[If you're replying point by point, please try to quote the lines you
are responding to. It will make the discussion easier to follow.]
Cris Shupp wrote:
Marnen,
You are fast...
Class variables... got it!
[...]
I really do not want to use a yaml file. Some of the config data will
include passwords to other systems that the worker threads will need to
perform their duties. Also, the admins will get cranky if I make them
modify a yaml file.
If I use a 'singleton' active record I do need to figure out how to
encrypt the password in the database.
Perhaps. But you don't need to take this approach.
If I use a static, err class variable, I am more than willing to roll
the dice and assume no one will dump mongrel's memory and hunt for it.
I am very willing to use the class variable approach,
This is the wrong approach. If I understand the problem correctly, your
first approach (using instance variables) is almost correct -- just get
rid of the initialize method as I explained above.
but I am highly
curious how to build a 'singleton' model to make use of the various
active record goodies (assuming I can delete it upon startup).
