Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
Do you need both akka and stm? –  om-nom-nom May 25 '12 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 May 26 '12 at 1:59
    
Agree that persistance happens more often than at the end –  Stas May 26 '12 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). –  faif May 26 '12 at 14:13
add comment

migrated from stackoverflow.com May 26 '12 at 10:04

This question came from our site for professional and enthusiast programmers.

3 Answers

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.

share|improve this answer
add comment

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):

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.