Hi Martin, 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)?
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. -- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
