4 ms·
The contract associated with the actor is generally that the actor is a persistent entity. Assuming that's the case, the service hosting the actor can be though
by yodon 5y ago
The contract associated with the actor is generally that the actor is a persistent entity. Assuming that's the case, the service hosting the actor can be thought of as publishing a contract that the actor in question will continue to exist in the prior/appropriate state until it is told to change its state. You can of course amend this contract to have actors with finite lifetimes in which case you are responsible for figuring out the details of how you want to do so. In this sense Orleans Actors are essentially a distributed database (its often helpful to think of it explicitly as such).
Asking "what if the actor doesn't have the state I expect" is essentially the same thing as asking "what if my database doesn't have the value I expect?" If you're worried about cosmic rays mutating your actor state randomly, the same would be true of it muting a database. If you're worried about some other process mutating the state of your actor, the same would be true of that other process mutating the state of your database.
As to the specifics of whether the Actor is idempotent, that would depend on the details of the operation the Actor is empowered to perform on itself. You could set it to behave in an idempotent way or not. It sounds like you're approaching the question from the standpoint of wanting all your interactions to be idempotent, which of course would be a reasonable contract to impose but it's not a requirement that Actors have to work that way, it just happens to be a good idea if that's a thing you want.
- yodon 5y agoAs followup to your question, here's an article[0] on the Orleans messaging constraints used in Halo 4 [0]https://www.google.com/amp/s/caitiem.com/2015/02/08/clarifying-orleans-messaging-guarantees/amp/ https://www.google.com/amp/s/caitiem.com/2015/02/08/clarifyi...
- brundolf 5y ago> If you're worried about cosmic rays mutating your actor state randomly I'm more worried about other pieces of code mutating the state "randomly" > the same would be true of that other process mutating the state of your database The difference with a database is that all of its data ("state") is always public. An OOP service, at least, usually holds some hidden state that may change its behavior but can't be inspected from the outside, which makes its behavior nondeterministic (modulo explicitly-documented contracts). If you're saying Actors (in Orleans or otherwise) don't generally have state that's inaccessible from the outside, then that seems like a reasonable mitigation for this problem
- yodon 5y agoIf the objection is to hidden state and behavior that can't be entirely predicted from the outside by inspection of public properties it feels to me like your objection is less about OOP and more about abstractions in general. I'm sure you've thought about this already and have strong opinions here, so please read this as me engaging in a conversation rather than me trying to lecture. The value of abstractions is the consumer doesn't need to understand the mechanism inside the abstraction, and the downside of abstractions is the consumer doesn't get to understand the mechanism inside the abstraction. If one always expects to be able to see through the veil, I think one is in effect saying I won't allow abstractions. That's powerful when the size of the system is such that it can be understood in its entirety, but it's punishing when the size is orders of magnitude larger than can be understood completely without abstractions by one person. Actors, at least from my experience, are a helpful way to merge the abstractions of OOP and Services, but by default they are not intended to rid systems of abstractions.