Hi Luis, Am Montag, 2. Juni 2014 22:46:29 UTC+2 schrieb Luis Medina:
I'm a little confused by your explanation. First you mention that "...the > affected database records are entity-specific... and no indexes are > touched. Hence, executing many Bookings in parallel causes no considerable > performance issues". But then you say that "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". Are you saying that the first > set of operations of updating an account with bookings is less intensive > than your second operation of storing the bookings themselves? If so, how > would splitting the work into 2 different actors help if they're both still > accessing the database somewhat simultaneously (one actor updates the > account information using the bookings and the other actor maintains the > bookings themselves)? > This is a purely database-specific thing: Imagine two tables, one for the accounts and one for the bookings. All accounts usually exist for an entity already, one only updates the balance but no field that is part of an index. As such, many connections for different entities can modify the data in parallel without having to wait for locks (that's InnoDB-specific). To add entries to the bookings table on the other hand, for every new row one or more indexes have to be updated. Hence, several connections working in parallel have to wait for each other even though they write data for different entities. > > Regardless, I don't see anything wrong to using persistence the way that > you intend. Essentially, the first actor sends the booking to a second > actor which persists it. Once this second actor has successfully maintained > the database (I'm assuming the database sends some sort of "ok" message), > then you go ahead and delete said booking from the actor's journal before > moving on to the next one. Seems like a pretty good use-case for > persistence actually. > > Glad to hear that. I assume that - to achieve similar functionality as a durable mailbox - it would make sense to set akka.persistence.journal.max-message-batch-size to 1 or another very low value to ensure that new messages are immediately written to disk? -- >>>>>>>>>> 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.
