How to avoid data dependencies between Actors

[dsavir]

"Push" - this approach declares that any update to any data that's required by another actor be immediately shared through a message. Upsides: All actors that need to know are immediately made aware of the new data, no pulling (request messages), no deadlocks, no enforced syncronicity. Downsides: Masses of unncessary messaging announcing new data (nagging?). If a dependent actor needs particular information once in a while, but the actor responsible for the data is updating it much more often then a large proportion of the messages are unnecessary. The idea of sending potentially hundreds of messages per second without justification leaves me uncomfortable as we might be affecting the system performance, especially as the solution grows.

Sorry for going back to this option, but if the only problem you have with this is "unnecessary" messages, than create only necessary messages. For example, if A needs to now status of B every second but B updates every 100 ms, A should subscibe to "one second updates" and B publishes status to subscribers every second.

In addition, in my program I had a general SendCommand message that was a string composed of sender:target:commandname:commanddata, so I could use loosely coupled messages, and also routing for cases where I wanted less coupling. My software is plugin based and had no problem with this method.

Just one caveat - in my program every actor inherited from one parent actor (some actors through a long heirarchy) so I used loosely coupled messages a LOT.

Good luck!

[drjdpowell]

drjdpowell wrote:

Noticed something on rereading an earlier post:

Thoric wrote:

"Enforced Dependency Heirarchy" - by ensuring there is a defined dependency heirarchy to the actor tree we can prevent deadlocks by creating an associated mono-directional syncronicity. If an actor has information that is required by another, a heirarchy must be defined that elevates the requesting actor above the data source actor.

It's not about information, it's about exerting control or using something as a service.  If A has info that B needs, it's fine for a common Caller to register B to receive published info from A.  And at the same time to register A to receive info from B.  Neither A nor B is "above" the over in this case.  The Caller is exerting control on both.  It's not a "Data" dependancy; it's a control or service dependancy.  Can also by thought of as a "Compositional" dependancy: if A uses B, then B can be considered a part of A.  B can be part of A, or A can be part of B, but they cannot both be parts of each other.

To me this is a "Natural Dependancy Heirarchy" that greatly simplifies things and seldom needs to be "enforced".

I made a couple of posts on LAVA, complete with figures, that I hope better explains the rules I apply to actor relationships. 

[T.L.]

Hi Thoric,

did you finish your tries and have you made a decision?

Who is your favorite? Why?

Best regards

Thomas

[PrimaryKey]

I am right now preparing a presentation that I want to give on Architect Summit. I will also post it here. It will be summarizing all the possible ways to communicate with actors and beteen actors and give performance characteristics and pros and cons of each.

So soon, hopefully there will be a unified resource to get info like this

[Thoric]

I'm still experimenting Thomas, I think it will be a few months before I find sufficient time to explore the three frameworks I'm interested in. And now there's a fourth contender: JKI State Machine Objects.

[drjdpowell]

T.L.,

   I have a youtube channel where I've made some videos on Messenger Library, if you want to get a feel.  There is also the Delacor youtube channel, which has lots of videos on the DQMH toolkit.