How the Actor Model Solves Transaction Deadlocks and Concurrency Issues
The article explains how concurrent transactions can cause deadlocks when resources are locked, and introduces the Actor model—combining data, behavior, and message passing—to give data its own active logic, thereby naturally handling concurrency and avoiding such deadlocks.
Problem
User A's operations: (1) begin transaction, (2) operate on resource 1, (3) operate on resource 2, (4) commit transaction.
User B's operations: (1) begin transaction, (2) operate on resource 2, (3) operate on resource 1, (4) commit transaction.
If both transactions run concurrently, A locks resource 1 while B locks resource 2, leading to a deadlock as each waits for the other.
Using a synchronized lock may break logical consistency.
The root cause is that data is passive and processed by others. In read‑heavy, write‑light scenarios with few transactions this issue is less visible, but it becomes problematic otherwise.
Actor Model
The Actor model is designed to solve concurrent transaction problems.
Actor Model = Data + Behavior + Message
Because data is passive in the previous example, the Actor model gives data its own behavior, preventing others from directly manipulating it; interactions occur only via message passing, ensuring that an actor can modify only its internal state.
Message passing is the foundation of the Actor model, analogous to sending and receiving emails:
User A sends an email to User B.
User B checks the mailbox at an appropriate time, receives the email, and processes it.
After processing, User B sends a confirmation email back to User A.
User A later checks its mailbox and receives the confirmation.
The email represents a message, and processing the email represents an actor performing behavior on its own data. Each participant has its own mailbox, and messages are handled in arrival order, which naturally supports concurrency.
Thus, the Actor model inherently possesses concurrency characteristics.
The slogan of the Actor model is “everything is an Actor,” similar to the object‑oriented principle “everything is an object,” but while objects are sequential, Actors are intrinsically concurrent.
Actors are independent entities with no direct references; they communicate solely through messages, which decouples them and simplifies parallel program development.
Message types and contents are arbitrary, akin to web services—only the message is transmitted, without needing to know its implementation.
Languages such as Erlang, Go, and Scala support the Actor model.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java High-Performance Architecture
Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.