Understanding grain state persistence

As we learned in earlier chapters, grains can correspond to real-world entities. For example, in our Distel application, HotelGrain represents the digital life of a hotel in our chain of hotels. UserGrain represents the user or customer of our application. These grains will process the messages received from clients. UserGrain should hold user details such as name and address, which we call state. There is a method to update state. If UserGrain receives a message to update the address, UserGrain will update the address in the in-memory local state so that it can send the updated address when requested later. What happens when the grain deactivates? The internal in-memory state is lost. The application won't be able to serve the updated address. So, it is important to persist the grain state in a permanent database such as SQL Server or Azure CosmosDB. With the state persisted in the permanent storage medium, the grain can load the state from...