CODEWITHSUNDEEP
concurrencyactor
ffff
ffff

Reputation: 3070

How to achieve MVCC in actor model

Let's say I have represented my Employee entity as an actor. I have 2 services also modeled as actors. Both of them manipulate the state of an Employee actor it has received by sending it messages. Now let's say both the services are processing the same actor. Now it is perfectly possible that an employee actor receive state changing messages in the following order from the two services A and B

Employee <- |a1|a2|a3|b1|b2|b3|

This is fine. But sometimes its not

Employee <- |a1|b1|a2|b2|a3|b3|

Maybe a2 was dependent on state changed by a1, but b1 changed it

In analogy to databases, we have transactions so that we can work with a single snapshot/version of the data throughout the transactions lifetime.

In imperative model, we would lock the whole employee object and update its state similar to how database would do it.

So is it possible that an actor can receive bulked messages that will be processed as one atomic series of messages? Or is my modeling of my data itself flawed?

Upvotes: 2

Views: 456

Answers (2)

Sergiy Chernets
Sergiy Chernets

Reputation: 427

Both of them manipulate the state of an Employee actor it has received by sending it messages.

Well. An Actor by definition does not share its state or its manipulation with any other Actor. Any state manipulation is transactional within the boundaries of one message handling. An Actor represents an aggregate in that sense. Messages usually are Domain events/commands and have scope and part of the Ubiquitous language. DDD reasoning helps a lot when thinking about Actors.

My two cents

Sergiy <><

Upvotes: 1

Vaughn
Vaughn

Reputation: 146

Since I don't know what a1-a3 and b1-b3 actually represent, I can only assume to answer the question correctly. To me it appears that your messages are too fine grained. For example, perhaps a1-a3 are trying to set just one attribute of data in each message. The same probably goes for b1-b3.

However, what your messages should be focused on is causing behaviors on the Employee, not in setting individual attributes. Thus, as you yourself suggest, design your messages as behaviors, where a1-a3 would collapse into a single operation request. This is often called the Command pattern, where you command/tell an object/actor to do something. Doing so will result in correct transactional boundaries per message.

Note that above I said "object/actor." You can/should use the same approach in your object designs, not just for actors. Think in terms of intention-revealing interfaces and telling your domain model what you want it to do for you, rather than treating domain objects/actors as dumb data holders.

That's my take on your question. HTH.

Vaughn

Upvotes: 5

Related Questions