Hey Carmen,
I'm a Scala/Akka Newbie; but I think the idea in Scala is to use Actors to avert most concurrency bugs.
So, essentially (Akka) Actors are things that can hold their own state, like Objects in traditional OOP languages.
External Entities can Message to Actor references to signal it to change its own state, or to respond with information about itself.
The underlying Akka system handles the serialization of those immutable Messages to the Actors' 'Mailbox' or like dedicated min-message-queues.
Typically, multiple entities could concurrently message to any Actor. So, the ordering of those incoming messages is random.
However, the Akka serialization of those messages ensures that there's no race-conditions to worry about.
This also precludes having to do locks, and therefore running into deadlocks.
I'm not sure if this means that you have to design your System such that Ordering doesn't matter (i.e. first Message to get to Actor wins); and then to handle Duplicate messages from
horizontally scalable Actor Cluster instances (i.e. one Actor crashes in mid-flow and its replacement sends a duplicate message)
Anyhow -- I'm DEFINITELY interested in seeing a good example of exercising the baseline concurrency test-cases using Akka-Testkit! Will post that interest so that we both may get help with that answer!
Cheers!
Dagny T