David Habb wrote:
In this example they use: static protected ArrayList pArray = new
The neat trick is this chat doesn't have to rely on a database or
something like memcached, or text files to preserve the chat and quickly
hand it out to new people joining the chat. Its persisted in-memory
from within IIS or the ASP.NEt worker process from what I gather, kinda
like an Application variable almost.
Now since RoR is deployed on Lighttpd, Apache, Litespeed, or whatever
there doesn't seem to be anything like this. ie: there is no
Yes, as I understand it, in ASP.NET on a single server, your app lives
inside a single process (or something equivalent to that). So static
class variables are maintained between the multiple threads that
process incoming requests.
You could do this in Rails if you were happy to live with one Rails
process. But Rails isn't threadsafe currently, which is why you
typically deploy Rails apps using several Rails processes, even when
you're on a single server. So, no, Rails can't do this in the same way
as ASP.NET can.
You should note, though, that if you ever have to update your app or
restart your server, you'll lose all that data.
Sure I could use a database but I really don't
want to hit the DB each time I get an AJAX call to get the latest chat
messages, or have to house clean them so only the 100 newest items
stayed in the table. Yes I could use memcached, but thats extra
overhead on my server I'd rather not incur if at all possible.
Campfire must use one of these methods, and it certainly seems to
manage. Hitting the database that often isn't necessarily such a bad
thing, and don't forget that you can use caching at the Rails level.
ideas I've seen is people witting to a text file - again - not ideal and
Well, the static variable method isn't scalable either. If you need to
add another server, static variables won't be shared between them. So
you'll *have* to come up with some kind of shared data store in order