>>Erlang isn't a magic bullet. It might make migrating processes fast, but it won't speed up migrating data.

Could you explain why to me? I just can't remember. I think I might be suffering from mnesia.

A link on mnesia (http://en.wikipedia.org/wiki/Mnesia) would have been helpful.

Explaining a pun spoils it though.

Indeed, but I think that he was trying to say that Erlang could have made this process more transparent for the users, without any disruption.

Out of curiousity, does erlang really support that kind of hot migration of running processes along with their data?

Until now I only knew that erlang can span multiple hosts - but only when you wrote your application that way?

What has really helped us in terms of machine migration (but at the cost of additional overhead) is running stuff inside Xen and OpenVZ virtual machines. Those can really be migrated seamlessly - often without a noticable downtime.

Erlang supports hot code migration, which allows you to use your new code in each process AFTER you merge the new code in. The processes that were running when you merged the new code will still be using the old code, until they end execution. This isnt really that big of an issue if you write your code in the erlang-way, which is using as many processes as you can to spread data, and then passing messages between the different processes. In this situation,each HTTP session would probably be running the old code, but each new one created would be running the new code.