With this module the Kladde gets a new runtime. Until now the database has held everything together: Two requests that want to change the same quote meet in SQL Server, and a row with a version number or a lock decides who wins. That works. It has a price, though: Every rule needs a path through the database, and every check can go stale between reading and writing.
Orleans takes the opposite path. Every quote gets a small object of its own in memory, and that object processes requests one after the other. Two simultaneous approvals arrive at this object in sequence, and the second one already sees the result of the first. Where this object lives right now, on which server and whether at all, is Orleans' concern.
In this module you put quotes, appointments and the sales pipeline into such objects, store their state, version it, test everything in a test cluster and finally bring the Kladde to Azure with two servers. This first lesson lays the foundation: the terms, the most important guarantee and Orleans in the Kladde's host.
Actors, and what is virtual about them
The actor model is older than most programming languages you know. An actor is an object with state of its own that can be reached only through messages. It processes its messages one after the other, and nobody reaches into its state from outside. Because only one message runs at a time, the code in the actor needs no locks.
Classic actor systems require you to create, find and tear down actors yourself. Orleans takes that off your hands. An actor is called a grain there, and a grain is virtual:
- A grain always exists, logically speaking. You don't create it, you simply call it with its key, say the grain for the
office
office-north. - If there is no object in memory right now, Orleans creates one. That is called activation.
- If a grain isn't needed for a while, Orleans cleans the activation up again (deactivation). The next call creates a new one.
- Where the activation runs, you don't know and don't need to know. The caller holds only a grain reference: type and key.
The terms you will need constantly in this module:
| Term | Meaning |
|---|---|
| Grain interface | The methods that can be called from outside, as a C# interface. Every method returns Task or ValueTask. |
| Grain class | The implementation of the interface, with the state as fields. |
| Grain identity | Type and key, written as type/key, for example counter/office-north. |
| Activation | An object of the grain class in the memory of a silo. For one identity there is at most one. |
| Silo | A process that hosts grains. In the Kladde that is the web server itself. |
| Cluster | All silos that know each other and share the grains among themselves. |
| Client | Code that calls grains. An endpoint in a silo is itself a client; a process of its own can be one too. |
"At most one activation per identity" is the rule this module builds on. In lesson 4.5.3 you will see that in rare cases it can be briefly violated when a server fails, and how the storage catches that.