Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Tuesday October 03, 2006
06:39 PM

Shared Nothing is in your future

[ #31211 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.
    • 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 sha
      • 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.