Reliable Actors
Reliable Actors API: Actors were introduced in the 1970s to deal with concurrent computation problems in parallel and distributed computing systems to simplify programming. From a logical point of view, actors are isolated, single-threaded, and independent units of compute and state.
In computer sciences, the dining philosophers’ problem is a great example to illustrate concurrency and synchronization issues that can be solved using actors. Wikipedia has a good article on this subject at https://en.wikipedia.org/wiki/Dining_philosophers_problem, which is worth reading if someone is not familiar with those types of problems.
With the advent of cloud computing, there are more and more use cases where actor-based applications offer a great advantage. Almost every application with multiple independent units of state, such as online games or IoT (Internet of Things) scenarios, are great use cases for actors. In the case of online games most of the times an actor represents a player, or in the case of IoT, an actor represents a device.
Service Fabric implements reliable actors as virtual actors, which means that their lifetime is not tied to their objects in memory. The advantage of virtual actors is that we do not need to explicitly create or destroy them. The Service Fabric actor runtime automatically activates the actors when needed and garbage collects them if they have not been used for a while. Once garbage collected, the actors are not really “gone,” as the runtime still maintains knowledge about their existence. The runtime also distributes the actors across the nodes in the cluster, and with that achieves high availability in the same way as we have seen earlier in this chapter. So how does that help with concurrency? Service Fabric only enables one active thread inside an instance of the actor code at any time. The runtime requires a complete execution of an actor method, for example as a response to requests from other actors or clients even though the communication is asynchronous. The complete execution is called a turn, and thus we speak of turn-based concurrency. Service Fabric makes it easy to use actors as the runtime does all the heavy lifting. As developers we just need to define the actor interfaces, implement them, register the actor implementation, and connect using an actor proxy, and the runtime will do all the heavy lifting, like synchronization and making the state of the actor reliable for us.