Handling application level concurrency - what's my options?

Question

We have a thin web layer (Scalatra) that translates incoming HTTP requests into events (case classes) that are sent to a thread-bound event processing actor. Some of the events contains the id of an aggregate root that we need to mutate for various reasons. The total amount of application data is too big to fit in memory, so we need to retrieve the aggregate, by its id, from a data source before operating on it. Of course we don't want the event processing actor to block, so the idea is to spawn a new (event-based?) actor that loads the data, mutates it and stores it back into the data source. Ideally I would like to handle concurrency in the application instead of relying on ACID capabilities of the data source. Basically I need serialized/transactional access to each aggregate.

Can this be achieved using actors? What would be the best approach? Keeping a ConcurrentHashMap inside the event processing actor containing actors keyed on aggregate root id?

Or do we have to involve STM:s (ScalaSTM/Akka) or something similar?

Answer 1

You can represent your "aggregate root" as an actor. When you want to mutate the aggregate root you can send a message to do so from your request handling actor. You can also have an intermediary broker actor that forwards messages to the correct actor and manages a cache of aggregate root actors ( by id ) by instantiating an actor representing the data on demand and stoping them as needed. STM will be needed if you need to coordinate a mutation across actors that represent data.