https://metaplay.io logo
Querying for Nicknames of multiple player entities
# questions-and-feedback
d
Hi, I'm wondering if there is an easy way to query the Nicknames of multiple entities? I am thinking I could: 1. Query multiple entities with an ask and do a Task.WhenAll to wait for them all to complete 2. Query the Database directly. In the metaplay sdk it looks like something like this is happening in PlayerListController for example. Any thoughts or recommendations? Thanks Andre
j
Invoking multiple concurrent EntityAsks and awaiting for them with Task.WhenAll is completely fine way to do this. For this I wouldn't recommend accessing the database directly. The PlayerListController and the Dashboard are a bit of a special case since we to view some data even if PlayerActor is crashing or misbehaving (and we can tolerate some delay in data). With EntityAsks do note that you need to be a bit careful that you don't have two entities Asking (and awaiting) each other at the same time, as that would Timeout. For example if you have Player A asking Player B, and Player B asking A, both are
awaiting
the response and cannot run the Ask Message Handler. One trick to avoid this is to not await and instead run the Asks in background then continue when they complete, for example
ContinueTaskOnActorContext(Task.WhenAll(...), task => { }, ...)
.
d
Cool. Thanks for the quick reply. much appreciated. Just to make sure i understand the last case and excuse my akka ignorance. Do Actors ensure only one message is ever processed at the same time and hence we need to ensure we return from the message processing function?
j
You got it exactly right. The incoming messages are put into actor's inbox and are handled from one at a time in order. A message can only be handled after the previous message has been handled, i.e after the handler method returns (or the returned Task completes).
awaiting
essentially blocks the message handling for the actor, and that means the actor wont reply to any Asks. So what this means is that if you
await
you can be sure no other message handler have been executed during this time and you can be sure the actor state is still the same as it was before you started awaiting. A far fetched example of this is something like:
Copy code
1. Check money
2. await someOperation
3. Do something with money
At step 3, you can be sure the assertion at 1 still holds. Some actor frameworks like Swift Actors choose to allow any operations during awaits. This breaks the assertion at step 3 but avoids the risk of deadlock/timeout. Akka chooses one-at-a-time logic, which keeps local consistency, but can deadlock/timeout if you actors await each other.
2 Views