11

I did a lot of self-study coding, got some experience with Parallel Programming Models: Actors, Software Transactional Memory, Data Flow.

When I am trying to apply these architectures to real life - into high load web application - any model doesn't support durability and persistence for data. Real life tasks requires to save data at the end. This means that still I have to use DB and trapping DB syncs, possible scalability bottle necks etc.

Does anybody knows good example of architecture (src or text or diagram or blueprints) that uses Akka Actors or Software Transaction Memory and implement persistence at the end?

Any good example/idea for Transactional Memory, Actors, Dataflow, Tuple spaces in real life applications is welcome.

Improve this question
4
  • Do you need both akka and stm?
    – om-nom-nom
    Commented May 25, 2012 at 22:05
  • It seems unusual that you consider persistence to be "at the end". I believe the "trapping DB syncs, possible scalability bottlenecks etc." are a problem precisely because they are in the middle of things, rather than the end.
    – Dan Burton
    Commented May 26, 2012 at 1:59
  • Agree that persistance happens more often than at the end
    – Stas
    Commented May 26, 2012 at 10:03
  • @Stas How is the question related with (1) Scala and Clojure, (2) best practices? What I've read is (1) language-agnostic and (2) related only with concurrency (in particular Durability/Persistence).
    – sakisk
    Commented May 26, 2012 at 14:13

3 Answers 3

Reset to default
5

Actor / STM models and database persistence are somewhat orthogonal - you can easily have one without the other, and I think there is a danger of confusing the two.

Achieving Durability (the D in ACID) is extremely complex in a transactional setting, and particularly in a distributed setting where you have actors / processes being co-ordinated by message passing. You get into thorny issues like the Byzantine Generals Problem.

As a result, I think there is always going to be some degree of tailoring the solution to meet your specififc persistence requirements. There are no "one size fits all" solutions.

Worth looking at (Clojure perspective):

Improve this answer
5

The actor model works pretty with with Command/Query Responsibility Segregation (CQRS), as messages to actors that perform data manipulation can be used as "Command" equivalents.

So, what does that have to do with your persistence problem? Well, you work on memory, and write all commands to a log, which is a cheaper operation because it's append-only, and dump snapshots from time to time to reduce the time required to reload the database if necessary (plus making it possible to recover space used by the log).

This is a pretty common technique. Look at VoltDB and Redis for further inspiration.

Improve this answer
4

Rich Hickey has a brand new brainchild called Datomic. It's a new approach to persistence, decoupling storage, transaction management, and querying. It's based on immutable records and uses a query language called Datalog (shares features with Prolog). The key goal was to allow easy distribution and cloud deployment. It relies on storage as a service (so not one concrete implementation, but loosely coupled through an over-the-wire API).

In Clojure we have STM which gives us ACI, the D missing. Datomic adds the D.

Improve this answer