Hello List, I have a question similar to one posted onto this list before <https://groups.google.com/forum/#!topic/akka-user/9f-J2PS1IYA>, but a little bit more specific.
This is the initial situation: - I have an existing application that uses MySQL as its backend. - Akka is already used extensively in this application. - The introduction of additional systems/backends should be avoided. I'll illustrate my problem using a variation of the classic "bank account example", an accounting system: Let's say there's an AccountingActor that handles messages of the type Booking. Whenever a Booking is received, the AccountingActor opens a database transaction, executes the booking (debits a given amount from one account and credits it to another) and commits the transaction. The point here is that many such actors can exist at any given time, each one representing the accounting of a single entity and thereby ensuring that Bookings for any such entity are applied in sequence. So far, so good: This works perfectly fine as the affected database records are entity-specific (InnoDB does its row-level transaction magic) and no indexes are touched. Hence, executing many Bookings in parallel causes no considerable performance issues. Now I'm in the situation that I want to keep the bookings themselves so I can display a "balance statement" and generate other more complex reports (that's why the data has to be stored in a relational database in the first place). All of the bookings are written to the same table in the database and when dozens of actors are trying to do so in parallel, this naturally causes locking issues on the database indexes and completely destroys performance. So I'd like to split the operation in two parts: First, execute the booking as described above, thereby changing the entity's state. After successful completion of the transaction, I'd like to forward the Booking to another actor which does nothing else but maintaining the Bookings table (appending new bookings, pruning old ones). The queue of this actor should be durable so - in case the system goes down before all of the Bookings have been persisted - it can continue its work after restart. My question now is: Durable Mailboxes seemed like exactly the thing I need, but they have been removed from Akka and replaced by Akka Persistence. In the post I linked to in the introduction, two possible approaches are outlined of which only the first one looks like what I'm looking for (immediately deleting messages once received/handled by a Processor). Yet, it kind of feels like using a feature actually designed for other cases to solve the problem (aka "a hack"). Am I correct in this perception or is this actually the recommended way to do this? Thank you very much for your suggestions. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
