4 ms·

Actors should be inherently persistent unless no longer reachable.

bsaul 7y ago
What i mean by persistent is : what is the best practice to save an actor’s state so that it can be properly restored in case of a crash without loosing information. I think i’m still not clear on how you would design a transactional system ( such as order & paiement processing ) with actors in a way that won’t make it look like a microservice based system ( aka : one per subtask, fetching info from a db for each incoming request, and storing the result in a db in the end) It seemed to me actors had to have a more fine grained context ( such as one per order), but in that case i’m wondering how it’s supposed to handle saving its state regularely so that no information on the order processing state is ever lost
- ProfHewitt 7y ago
  Excellent question! But your question seems to make the unfounded assumption that application programmers should be in charge of restoring crashed Actors. Instead, an Actor System should restore Actors as best it can based on recordings that it has. Applications must be made resilient against any and all kinds of inconsistencies that will pervasively arise.
  - bsaul 7y ago
    Do you know any resource i could read that would explain how all that is supposed to work out in practice ? I've never heard of an actor system able to automatically respawn actors with their previous state (the whole system would look like a tree of cached data, each layer responsible for saving the leafs under it, with a huge "persist to DB" on top , wouldn't it ?). Does erlang OTP do those kind of things ? Edit: also, are you Prof "Carl" Hewitt ? The one that invented actors ? I'd be honored you found a question of mine about actors excellent...
    - mathgladiator 7y ago
      This is what I am building. I'm building a database of actors that are free agents in a way. The key insight is that an actor is a tiny VM and you just need to make the VM state durable.
      - bsaul 7y ago
        I see many challenges : - not all states transitions need to be durable. If performance matters you’ll have to get your actors to call something like a « saveState » from time to time, otherwise every single property change is going to have an overhead in terms of performance. - what does « durable » mean ? Surely, just having the state of an actor saved in the memory of the supervisor isn’t enough. If the two are on the same server and the server shuts down, it’s game over. You need a « persistence » service / actor, but that thing is going to have to persist the state of all the actors in your system. I don’t see how that can work if you’ve got millions of actors running in parallel.
        ProfHewitt 7y ago
        Durability is a matter of degree. Lowest is to record in RAM. Next is persistent local storage. After that comes storage on other machines.

What i mean by persistent is : what is the best practice to save an actor’s state so that it can be properly restored in case of a crash without loosing information. I think i’m still not clear on how you would design a transactional system ( such as order & paiement processing ) with actors in a way that won’t make it look like a microservice based system ( aka : one per subtask, fetching info from a db for each incoming request, and storing the result in a db in the end) It seemed to me actors had to have a more fine grained context ( such as one per order), but in that case i’m wondering how it’s supposed to handle saving its state regularely so that no information on the order processing state is ever lost

ProfHewitt 7y ago
Excellent question! But your question seems to make the unfounded assumption that application programmers should be in charge of restoring crashed Actors. Instead, an Actor System should restore Actors as best it can based on recordings that it has. Applications must be made resilient against any and all kinds of inconsistencies that will pervasively arise.
- bsaul 7y ago
  Do you know any resource i could read that would explain how all that is supposed to work out in practice ? I've never heard of an actor system able to automatically respawn actors with their previous state (the whole system would look like a tree of cached data, each layer responsible for saving the leafs under it, with a huge "persist to DB" on top , wouldn't it ?). Does erlang OTP do those kind of things ? Edit: also, are you Prof "Carl" Hewitt ? The one that invented actors ? I'd be honored you found a question of mine about actors excellent...
  - mathgladiator 7y ago
    This is what I am building. I'm building a database of actors that are free agents in a way. The key insight is that an actor is a tiny VM and you just need to make the VM state durable.
    - bsaul 7y ago
      I see many challenges : - not all states transitions need to be durable. If performance matters you’ll have to get your actors to call something like a « saveState » from time to time, otherwise every single property change is going to have an overhead in terms of performance. - what does « durable » mean ? Surely, just having the state of an actor saved in the memory of the supervisor isn’t enough. If the two are on the same server and the server shuts down, it’s game over. You need a « persistence » service / actor, but that thing is going to have to persist the state of all the actors in your system. I don’t see how that can work if you’ve got millions of actors running in parallel.
      - ProfHewitt 7y ago
        Durability is a matter of degree. Lowest is to record in RAM. Next is persistent local storage. After that comes storage on other machines.