Hi Ashley, it is good that you ask these questions! [answers inline]
On Tue, May 6, 2014 at 8:28 AM, Ashley Aitken <[email protected]> wrote: > > > I thought reactive applications were all event-based and, in particular, > events could be generated and flow through an application from GUI back to > GUI. > Yes, “reactive” means that all components react to change and disseminate change in a way that focuses on the flow of information across the application. This is crucial in achieving scalability and bounded latency (i.e. responsiveness). > > Does the way Akka Persistence Views work prevent this (since they are, if > I understand correctly, essentially polling for events)? > Conceptually a View models how data flow from one persistent actor to another actor, so on that level it is in accordance with Reactive Principles. You are correct to point out that the need for polling in the current journal and view implementations incurs latency overhead that is sometimes unnecessary, but on the other hand it also allows the batch processing of updates which makes the execution on today’s hardware more efficient (see Smart Batching). It is a trade-off and as such there is no generally “best” solution. We will certainly see improvements and optimization work in this area, especially concerning the streaming of events from truly reactive journals with Reactive Streams. But that requires the journal implementation to support such a scheme in the first place. > > Can a reactive path be constructed in another way with Akka Persistence > that can be used in distributed applications? > Instead of relying on Views you can of course send events as normal messages from one actor to the next, which would achieve what you are asking for. > > Are reactive applications compatible with the "eventual consistency" of > CQRS? > They are not merely compatible with it, the need for distribution that arises from the Scalability and Resilience traits forces us to abandon sequential consistency in favor of a weaker model that supports distribution (see also CAP theorem and Pat Helland’s paper on “Life Beyond Distributed Transactions”). CQRS is a data model that is geared towards achieving high availability and sufficient consistency at both the write and read sides of a system, and as such it very much supports the design of reactive applications. In fact I do not currently know another model which comes as close to the ideal as CQRS/ES (which benefits greatly from DDD). > > Please excuse my ignorance if this question doesn't make sense and I am > not criticising anything, just trying to understand. > Your questions do make a lot of sense and I hope I could help you with my answers. Regards, Roland > > Thanks, > Ashley. > > -- > >>>>>>>>>> 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. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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.
