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 (Score:1)
Re: (Score:2)
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
Re: (Score:1)