search

dspeele / react-vs-shared-state-inventory

Reactive v Shared State Concurrency: Inventory Mgmt w/ Scala/Play/Akka & MongoDB - Example Applications
0 stars 1 forks source link

Mongo locking in Akka project #1

Open kervinpierre opened 9 years ago

kervinpierre commented 9 years ago

Hi Dana,

Is the Akka side locking? Otherwise how do you synchronize the inventory count serialization.

If it's not locking, shouldn't the shared side not lock as well?

Best regards, Kervin

dspeele commented 9 years ago

The Akka side doesn't need locking when designed properly. Actors have mailboxes (queues) and process the messages they receive serially. Since we only have one updater actor per product and it is the only thing that can update that product (and only processes one message at a time) we don't need a lock since there is no concurrent access to the memory. The shared state side does need a mechanism to prevent concurrent access to the updateQuantity method for each product's InventoryQuantity instance since it has no such mechanism for enforcing serial access. So a lock (or CAS) is necessary.

kervinpierre commented 9 years ago

Hi Dana,

This is getting clearer. Thanks for all your patience explaining all of this.

  1. As far as I've seen Akka is performing the job of the queue at this point. This is very common ( as least as far as I've seen ). Queues and Akka are often interchangeable to some extent in simple applications.
  2. AkkaSystem is managing the threadpool that the Actors are using.
  3. The shared state side can forego locks in the same way as the Akka side. The threadpool threads or "listeners" would each have a queue of incoming updates.

It's not as bad as it may sound

A. The threadpool is initialized at application start use an ExecutorService B. Each thread in that pool has a ConcurrentQueue of some sort for receiving requests. E.g. ConcurrentLinkedQueue C. The call registers a callback with the request object D. The threadpool is only stopped when the application stops

I've been think of removing the Play dependency and then use something like https://scalameter.github.io/ to microbenchmark the 2 approaches. That way the only external feature required would be MongoDB.

dspeele commented 9 years ago

Great idea, Kervin! I totally agree that this would certainly even up the playing field to a large degree. But this would be handling concurrency with a consumer-producer paradigm rather than a shared-state one. That said, it's all semantics and it would be fun and informative to see how Akka would stack up there. Cheers and thanks for keeping this conversation going... it's great that we've gotten so much mileage out of a couple of toy apps.