Is the Actor Model an alternative to transactions?

Question

I know that transactions use locks. It is claimed that actors liberate us from shared state and locks

make sure all crashes are the same as clean shutdowns: this can be done through practices such as shared-nothing and single assignment (which isolates a process' memory), _avoiding_locks_.

Is the Actor Model an alternative to transactions? Does it liberate us from transactions?

I read that Reactive Akka revolutionized the parallel programming but I see that it just broke the locks into atoms giving you something low level like assembler language to build desired locks (with custom timeouts) yourself. The fact that you can add timeouts makes blocking calls and locks fault-tolerant, as I understand. But, you have to make them manually at the low level.

What is so revolutionary here? Are we saved from transactions? I see that it can be necessary for some actor to lock one or more other actor(s) to send them several updates such that no other actor interferes. This is called "shared state", "locking" and transaction. I do not understand how Actor Model saves us from them and revolutionizes anything.

Alternatively, consider a simple actor model: multiple processor actors + memory actor. How do you program it without the locks? I know that it is unfortunate example. But, how can you be sure that there always are fortunate ones? Please help me understand beside the lapidary actor model verbiage.

Answer 1

You state correctly that transactions and locking are needed to deal with shared mutable state. And also that in an actor system, there is no shared mutable state. So it seems you've already answered your question yourself.

I see that it can be necessary for some actor to lock one or more other actor(s) to send them several updates such that no other actor interferes.

I don't quite follow you here. Why would you design a system like this?

This is called "shared state", "locking" and transaction.

No, I think this conclusion is incorrect. As the state is encapsulated within an actor, and can only be modified by sending messages to this actor, this state would not be considered shared - it's owned by the actor, he doesn't share it with anyone. Updating this state by sending messages would not involve locking or a transaction. Concurrent modification is ruled out by the sequential message processing of the actor, which is sometimes referred to as the "single thread illusion".

I do not understand how Actor Model saves us from them and revolutionazes anything. Alternatively, consider a simple actor model: multiple processor actors + memory actor.

Again, this seems to be an atypical design. What is a "memory actor" supposed to be? Why would you separate the processing from the state?

I have a feeling you are attempting to transfer an existing solution to a radically different archtitecture, which is bound to fail. Rather than trying to make actors behave in a way you're used to, you should embrace that it will need a different approach. You might find it valuable to read something about designing actor based systems, e.g. "Reactive Design Patterns".

Answer 2

Actor model doesn't magically solve all the troubles. It just makes such an abstraction of concurrent programming that helps reasoning about solutions.

There are two major aspects of Actor Model, which make it very useful in my practice.

First of all, when IT solves a business problem, what it does is effectively translates business processes and rules to the language of computers. But business processes are built around people in some organizational structures. And Actors model this structures well with supervision, not sharing internal state and monitoring. Then, business processes are built by people for people - so, they assume reasoning by people and usually are quite comprehensible. So, modelling with actors aligns quite well with business problems and fits human brain.

Second, actors are VERY useful at modelling timeouts, risky tasks, short circuits, exponential retries and so on. Again, supervision and monitoring helps.

As far as transactions are concerned, the first mentioned aspect covers them. Transactions can be modelled with actors just as they are used in human world. Think Two Generals' Problem . Actors' communication is asynchronous. If you use actors - you just live with it. So, you either have at-least-once delivery (if you add acknowledgement) or at-most-once (Akka's default). So, choose what fits your problem and model transactions with it. Though you probably end with more lines of code, but the benefits are simpler abstractions and scalability out-of-the-box.

I also should add that all mentioned qualities of Actor model make it an ideal fit for Domain-Driven Design based on Hexagonal architecture, with or without Event-Sourcing. My use of Akka is just that. And DDD is quite concerned about domain transactions.

Answer 3

Frameworks like Akka or broader, frameworks based on event-driven concurrency model, primarily optimize the use of processing power by parallelizing workload in the most efficient way - by removing the need for context switching between threads, blocking on I/O operations, and by maintaining thread-per-cpu sized pools saturated with cpu-bound tasks.

In case of Akka, it also frees from the problem of access to shared mutable state, but only within the boundaries of a single actor (effectively an actor is a synchronized resource without the need for handling locks and blocking threads and with no deadlock potential) and it does so by making the access sequential. The problem of handling shared mutable state in a consistent way and atomicity of operations across multiple actors of course remains.

So you are correct in that actor-model doesn't solve the problem of shared state entirely, but you are denying your own claim, as no one really thinks so.