27 aug 2014 kl. 19:27 skrev Ashley Aitken <amait...@gmail.com>: > On Wednesday, 27 August 2014 23:08:27 UTC+8, rkuhn wrote: > > In theory if Client sends a command to A which in order to fulfill it will > need to send a command to B then A’s response to the Client will contain B’s > reply in some capacity. Whether there are cases where this structure becomes > impractical is something I cannot tell with my current knowledge. > > No, I believe there are use-cases where a process manager listens for an > event without having first sent a command to the aggregate root producing the > event. An example could be a process manager listening for any ItemPicked > events and starting a process to check the stock levels and possibly reorder, > separate from the sales process. Again this seems to require a reliable > publish-subscribe facility for events. > > Yes, this is a good point: I was thinking of ephemeral (per-request) process > managers, for which I still believe that the message flows should be > organized such that the PM does not need to subscribe to events—that would > impose too much overhead. > > I understand the concerns about overhead on the read-side but wonder how > other CQRS/ES implementations handle this. I asked a question related to > this on Stack Overflow and received an interesting answer (explained fully in > the comments): > > <http://stackoverflow.com/questions/25458870/events-on-write-side-of-cqrs-for-saga-process-managers>
Thanks for the link, this is indeed interesting. I think with Actors we have more freedom to optimize, but I agree that in principle the PM acts based on Events. > > Your example of a “standing” process is exactly one of those read-side > consumers that we have in mind for the proposed PersistentView replacement. > > I apologise if I am misunderstanding what you mean by "read-side" but this PM > issues commands so I had assumed it must be on the write-side. If you mean > using PersistentView(v2) makes it read-side (I assume one could use > PersistentViews on the write-side) then that's ok. Well, obviously a PM wears multiple hats in this game since it is involved both with commands and events. > > Please consider also this diagram, similar to the last one I shared: > > <https://www.dropbox.com/s/cqfabcjzbbvruuj/annotated-detailed-architecture-overview.png> > > IMO: Write Side = [1] + [2], Read Side = [3], but I see the similarity of > [2] to [3] in a round-about way if the client is included. > > There is a fundamental difference between commands and events: if a command > is lost then the contained intent evaporates and nothing happens, the sender > will eventually recognize this and retry or abort the transaction. > > Yes, I had thought this as well based on what I had read but again from the > comments to the Quora answer: "If your commandbus is not reliable, you can > use a timeout mechanism (i.e., check for expected result of command after > some time), but this requires reliable timeouts." Yes, if the PM is really the final entity driving things, then yes, you need reliable timeouts. If the ultimate driver is some external client then that will restart the process (if desired) if the PM does not reply within a certain amount of time, obviating the need for the PM to be 100% reliable. > > Does Akka have a reliable timeout mechanism (which I assume it means work > across crashes)? We recently merged a change that restarts the entities in ClusterSharding based on which ones were active before a crash, I think this would solve this issue (assuming that each entity properly persists that it was waiting for something). 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 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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.
