Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Clustered Scala

  • submit to reddit

There has been a lot of discussion about the different concurrency models provided in languages like Java (shared-state) vs those provided in languages like Scala and Erlang (message-passing). The latter languages use an actor-based model that relies on setting up independent actors and (reliably) passing messages between them, rather than coordinating access to shared state. The actors run as lightweight thread-like entities and are expected to exist in large numbers (far more than the typical number of threads in a Java program).

The advantage of the message-passing model is that it is harder to encounter many of the common problems in shared-state models. Each piece of code is independent and deterministic which makes it easy to test. The pieces fit together in ways that are easy to model and reason about (well, easier than shared-state systems maybe).

Scala makes it easy to use actors and message-passing on top of the JVM. This gives us interesting new possibilities for using message-passing paradigms with the stability of the JVM. It may also let us do that a bit under the radar as most enterprise ops centers know how to deal with the JVM, when they might not be as comfortable running something like Erlang.

So, this lets us make interesting new systems based on message-passing, but how do we scale out those systems once they're too big for a JVM instance? Today mad scientist Jonas Bonér announced support for clustering Scala actors using Terracotta.

Terracotta is typically used to cluster Java applications by sharing the heap and lock state across nodes. However, this is done using runtime bytecode manipulation and the most important bits are based on the JVM, not on Java. Since Scala is based on bytecode, it was possible to extend the Terracotta infrastructure to also handle Scala actors.

If you're interested in Scala or Erlang actor-based concurrency, try it out with Terracotta to build a distributed version as well!

[ Note: I work at Terracotta, so I am entirely biased. But c'mon tell me this isn't cool! :) ]



Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)