CODEWITHSUNDEEP
spring-bootakkaactor
BdEngineer
BdEngineer

Reputation: 3189

How to handle and updated a shared hash map in Actor System?

Hi, I have meta-data , HashMap object , need to be accessed inside my Actor class, and need to be looked up. If found key I should used it inside the Actor business logic. If not found I need to create one key and value and update the HashMap object.

So how to handle this in Actor System? as you know each actor instance would generate a not-found-key simultaneously which would result in duplicate and inconstant. So what is the industry standard to handle this scenario? Please provide your advice how to handle it.

Upvotes: 0

Views: 211

Answers (1)

Allen Han
Allen Han

Reputation: 1163

If I understand you correctly, your situation is such that you have one hash map that is accessed in multiple actors, and you want to know how to keep a consistent state in the hash map across all the actors.

There should be one publisher actor and several subscriber actors. The publisher holds the canonical copy of the hash map. The publisher first sends a copy of the hash map to all the subscriber actors. These subscribers start performing business logic on the hash map.

When the business logic in a subscriber actor wants to update the hash map, it sends a message to the publisher actor. The subscriber does not update the hash map in its local actor state. Instead, it waits for the published hash map from the publisher.

The publisher actor accepts the key-value pair from the subscriber and uses it to update its canonical copy of the hash map. It then publishes that updated hash map to all the subscribers.

There are two ways for the subscriber to send its key value pair to the publisher. One is asynchronous, the other is synchronous. The first uses tell, the second uses ask. Tell is lightweight, ask is heavyweight. Ask has the advantage that there is no gap between sending the update to the publisher and receiving the updated hash map back. Of course, the subscriber that did the ask will receive two copies of the updated hash map: the first time as the response to the ask, the second time when the publisher publishes the hash map to all the subscribers. This does not cause any issues since Akka guarantees that messages sent first will be received first. For that reason, and the fact that no local updates are occurring on the hash map, the second published version of the hash map will never cause a recent write to be temporarily deleted from the hash map. Just to be safe, you may want to include a flag in the published message telling the subscriber actors which one of the subscribers can ignore the published hash map since it has already received it as the response to an ask.

This solution will guarantee a consistent hash map state, but this synchronization method may not be adequate for your application. The subscriber actors can overwrite each others' changes, and this may not be what you want. To prevent this situation, it may be necessary to separate business logic in the various subscriber actors.

Upvotes: 1

Related Questions