I am just looking for a bit of advice about how to go about the title to this question.
I currently have an asp.net core application which is backed by entity framework using DDD pattern that we are looking to migrate to a microservices architecture with service fabric.
I am aware that actors can be persisted to disk and to memory, but does anyone have any experience with actors being persisted to an external storage such as MSSQL?
The reason this comes about is that currently we run into concurrency issues with entity framework and actors would seem a good fit for this as they are single threaded and distributed, however i can't seem to find any material to suggest that actors should or could be backed by database persistence.
The only reason we need the database (and not a stateful actor as such) is that SSRS links to the database to provide reports.
So the question really is
Any help, guidance or suggestions are more than appreciated.
You didn't find examples about this approach because the main idea of actors in Service Fabric is to use the state management features of the platform to handle that for you.
The framework is flexible to write your own provider, but will be harder than doing on another actor framework like Akka.Net or Orleans that are not built on top of a platform like SF.
SF Actors has a DNA from Orleans, a framework on which SF Actor was ported from.
Orleans does not provide a data platform and requires Storage Providers to Handle the persistence, for a SQL Storage you could create a custom provider and register it to the runtime and is all done. They already have one for Azure Table Storage.
If you still have plans to store the state on DB, you can opt for one of those solutions, or create a custom provider as suggested by Loek, and base it on ideas taken from one of the other frameworks.
Regarding the main problem, you don't have to actually use the actor state management to solve your concurrency problem, you could just use the isolation and communication aspects of it to prevent concurrent operations against a single Item(being each item an actor) and all operations against an item data should be handled by the actor itself.
But, because you are using an external persistence, nothing prevents other actors, services or external systems of changing the actor state, and technically it is open to concurrency again. Might not be an issue if you can guarantee that only the actor can change it, as example, Azure Storage you can lease a blob, and only the lease holder can change it.
This is one of the reasons the actor state should be encapsulated and managed by the actor, otherwise the complexity to manage it will leak outside of the actor.