I realize I wasn't entirely correct when phrasing the persistence feature as "for documentation purposes". It is actually needed for the end-user work flow, but then in less vital operations. Alarms in nature need to be handled or escalated if necessary (and thus represent state changes), but most important we need to always be able to present the alarms when they are raised. The persistence of the alarms is not so vital from that perspective.
On Friday, January 30, 2015 at 3:22:11 PM UTC+1, Roger Varley wrote: > > I'm not an expert with Akka & persistance, but if your persistence is for > auditing only and not on your critical path, couldn't you treat your > persistence as a "sub-system" and use a T-pattern. When your event arrives, > you send the incoming message two ways, once into your persistence > "subsystem" in a fire and forget approach, and a second copy continues down > your critical path, so in effect, your critical path doesn't care if the > event gets persisted or not. > > Just a thought. > > > > -- >>>>>>>>>> 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.
