Shared Nothing is in your future

ziggy on 2006-10-03T23:39:38

The writing is on the wall - shared-nothing systems are in your future:

Let's be clear that the JVM has been lurching toward a shared-nothing model already for well over five years.

The servlet model, the EJB model, the Jini model... these are all in various ways attempting to provide semi-shared-nothing models so we can each contribute our own isolated parts to the whole. Unfortunately they're each anachronistic, one-off, partial solutions. JSR 121 is attempting to make this even more general for all kinds of pojo scenarios.

Given the isolation model that just comes for free with Erlang, the vast majority of the complexity and variation of these lurches toward isolation for Java would just go away. (Erlang itself has a *little* cruft but that's nitpicking.)

Haskell pushes you in this direction, because "shared nothing" is the default state; making a multithreaded program is somewhat easy, and making a shared memory multithreaded system actually takes a decent amount of effort and wizardry. PHP also pushes developers into a "shared nothing" model, which is rather telling.

Even if Erlang isn't in your future, chances are that lessons from Erlang are in your future. There's something to be said for high performance, highly scalable systems that are ready for massively multiprocessor (and multi-node) systems.

---

PHP's shared nothing

perrin on 2006-10-04T21:02:43

I always thought that the argument Rasmus made about PHP being scalable because it didn't share anything by default was kind of silly. I mean, you could say the same thing about bash-scripting. (Or Perl, of course.) To make an interesting multi-page web application, you have to introduce some kind of state, usually via sessions of some kind. The mechanisms for saving and restoring state aren't fundamentally different for Java than they are for PHP: cookies, a database, etc.

Re:PHP's shared nothing

ziggy on 2006-10-04T21:12:46

If you commit to saving and restoring state, then the options are pretty much the same.

The difference is when you start persisting state in memory, share it across threads, and expect it to always be there by design. That's when you start to see scalability problems: session affinity becomes a requirement, max users per server, max concurrent connections per server, hunting and killing long running processes, etc.

That's the kind of resource management that gets you in trouble, and makes you move toward shared nothing, either by convention (the Java framework of the week), by enforcement (PHP, Erlang, Haskell).

Re:PHP's shared nothing

perrin on 2006-10-04T21:18:59

None of the Java servlet implementations I used stored state in memory. Maybe that was done really early on, or is an option on some of them. It's certainly not the norm.