Here's a pertinent reply from Patrik to me: On Mon, Mar 3, 2014 at 4:07 PM, Richard Rodseth <[email protected]> wrote:
> I haven't looked at the sources, but it seems that passivation and > clustering could be orthogonal? > yes, indeed, the high level description: - all messages are sent via the Manager actor, which creates child Aggregate instances on demand - when receiving a message the Manager extract the Aggregate identifier from the message - the Manager creates a new child Aggregate actor if it doesn't exist, and then forwards the message to the Aggregate - the Aggregate can passivate itself by sending a Passivate message to the parent Manager, which then sends PoisonPill to the Aggregate - in-between receiving Passivate and Terminated the Manager will buffer all incoming messages for the passivating Aggregate - when receiving Terminated it will flush the buffer for the Aggregate, which can result in activation again The PoisonPill can be replaced with some other custom stop message if the Aggregate needs to do further interactions with other actors before stopping. The number of characters to implement this is probably less than what I have used in this description :-) On Mon, Apr 14, 2014 at 11:37 AM, Konrad Malawski < [email protected]> wrote: > Hello Kuba, > Firstly, thanks for the Akka love! We <3 you too ;-) > > Back to your questions: > Yes, the Actor would represent an Aggregate; and yes, it's a good idea to > spin up Actors for specific ID's, handle the command / event in it, and > emit more events signifying some business logic was performed on it. > You'll want to have a look at *EventsourcedProcessor* > http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#event-sourcingfor > driving such interactions (you can easily > *persist() *events from it too). > > The sentence you refer to from the docs handles this scenario: Your > processorId is "crazy-bob-222", and the processor fails (or you turn off > the system) - when the Processor recovers, it should replay events for > "crazy-bob-222", > so from the outside it'll seem as if there never was a failure - all the > events for this processorId will have been replayed in the Processor, so > it's up-to-date again. By incarnations we mean if you create new Processors > that should > work for the same user ("crazy-bob-222"), you should use the same > processorId - which causes the replay to happen. > > As for the Journal question. It's actually up to the Journal plugin where > to store stuff. (Journals have pluggable implementations - for mongodb > you'd use a community provided one from this list: > http://akka.io/community/ ). > The most common approach is indeed keeping a collection for "akka events", > in which the processorIds would be used as keys - so if we're replaying > events for "crazy-bob-222" the plugin would do a select for these documents > / rows with this ID. > > If you'd be able to build up an example Activator template that would be > completely awesome! If you need any tips let us know :-) > > I hope this helps, happy hakking! > > > > On Mon, Apr 14, 2014 at 7:44 PM, Richard Rodseth <[email protected]>wrote: > >> Take a look at the "cluster sharding" activator template, and some of the >> answers to my questions on this group. I think it would be nice to have an >> Activator template for DDD/Akka Persistence that didn't depend on a cluster. >> >> >> On Mon, Apr 14, 2014 at 9:46 AM, Jakub Czuchnowski < >> [email protected]> wrote: >> >>> Hi everyone, >>> >>> This is my first post on this group so for starters I'd like to thank >>> the Akka team for the awesome product. Love it. >>> >>> I was just going through the Akka Persistence documentation and I was >>> wondering how to achieve the event sourcing functionality as it is used in >>> Domain Driven Design. For example, when I get a command to modify an >>> aggregate with some particular id, is it a good idea to instantiate an >>> actor for that aggregate and additionally a processor to retrieve the >>> current state and then persist the new event? I guess my insecurity comes >>> from the statement in docs that "A processor must have an identifier >>> that doesn't change across different actor incarnations.". >>> >>> Additionally how this solution will be represented in MongoDB? Will all >>> the events for the aggregate type will land in the same collection? >>> >>> Sorry if I'm asking these qestions too early in my own research and I >>> could have found a solution myself, but maybe someone has already done it >>> and could shed some light on this particular use case. >>> >>> Thanks, >>> Jakub >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> -- >> >>>>>>>>>> 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. >> > > > > -- > Cheers, > Konrad 'ktoso' Malawski > hAkker - Typesafe, Inc > > <http://www.scaladays.org/> > > -- > >>>>>>>>>> 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. > -- >>>>>>>>>> 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.
