Is the Actor Model an alternative to transactions

actor-modelakkalockstransaction

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.

Best Answer

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".

Related Topic