Is ReadEntityState one reason it is called "actor-like"?

[douglasware]

Hello all,
I've been reading papers on actor model going back to the 1970's and if I understand correctly (a big if) client.ReadEntityStateAsync breaks the rules because it is not message based. In other words, I can signal an entity which will cause its state to change, but a subsequent client.ReadEntityStateAsync will return old state until the message is processed by the actor. As I understand the classic model from the papers, the entity state should be private and not readable except via a message.

If I implement read-state as a message the actor understands and Call it from an orchestration, does Durable Entities ensure the the state setting signal (which exists outside the orchestration as a REST API for example) is processed before the read-state Call operation?

Thanks in advance for the education!
--Doug

[ConnorMcMahon]

You are correct that ReadEntityStateAsync() is the main violation of the message-based actor model.

Calling an entity from an orchestration is effectively a signal that also waits for the entity to send an external event back to the orchestration with a result.

Because we guarantee that operations will execute in the order that they are signaled, this will have the actor-like behavior you expect.

[olitomlinson]

Thanks for taking the time to make the distinction clear, there!

I guess the point I'm failing to express is that by the time a call response is marshalled back to the client (via an orchestration result) another operation could have modified the entites state, so the response that the client receives could be already stale? (We're outside of an Orchestration so the LockAsync is no longer providing any guarantees?)

Do I have at least that bit correct?

[sebastianburckhardt]

Haha, yes of course you got that right. This is generally true for working with shared data in a concurrent environment. For example, when you read a shared variable in a multi-threaded program: by the time you get the result of the read the variable may already have been changed again.

[olitomlinson]

Great!

I was generally speaking in reference to this suggestion

Another option might be to create a short-lived, implicit orchestration whose job it is to simply handle the entity response and then complete. The client could then poll that implicit orchestration, waiting for its completion. The output of the implicit orchestration would be the entity response.

This would give better results than ReadEntityStateAsync as the result would have at least passed through the phase when it was very recently linearizable, but it could still be stale (as you described above), but possibly/likely less stale, than what may come from ReadEntity... ?

Am I close? haha

[sebastianburckhardt]

Yes, using a orchestration to wrap the CallEntityAsync means that we get linearizability. From a consistency perspective, that is as good as it gets. It has some other disadvantages though: it is not very fast (extra indirection, and the polling for completion) and leaves an instance and history in storage, which will then show up in user queries and likely confuse them.

[douglasware]

It also creates a lot of code ceremony which I see as a big downside.