ASP.NET Chat ability - can I do this in Rails?

David Habb wrote:

RE: Simple Chat asp.net + Ajax - CodeProject

In this example they use: static protected ArrayList pArray = new ArrayList(); 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 "application state".

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.

Other ideas I've seen is people witting to a text file - again - not ideal and not scalable.

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 to scale.

Chris