Mike, The case of CQRS usually has the service layer publishing the events in response to commands, domain events has nothing to do with it. If you're talking about event-based persistence on the command-side, again, domain events have nothing to do with the bus.
Cheers, -- Udi Dahan -----Original Message----- From: rhino-tools-dev@googlegroups.com [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols Sent: Wednesday, August 04, 2010 4:46 PM To: Rhino Tools Dev Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting If I have 5 events that took place on my aggregate root during the course of a unit of work. My understanding is that the root represents a transactional boundary. So I publish the events on the bus as a batch. The subscriber (in this case, denormalizers for events that write to a database) will go through each event and update the database, ideally in a single transaction so that if one of the handlers fails, then they all fail. As I think about it, I am not sure why that is so important other than the convenience of having NHib in a single session and cut down on the number of roundtrips. But I realize this is an impl detail that shouldn't be the driver. @Udi - I actually went back and forth on whether to publish these individually or not, so it is helpful to hear from you on this. Can you see why I would consider the batch a single unit though? If you are using a denormalizer you always only send one event at a time to that endpoint? On Aug 4, 6:35 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: > Then I'm afraid it sounds like you're not using DomainEvents the right way - > each event from the domain should be a discrete domain occurrence. > > -- Udi Dahan > > -----Original Message----- > From: rhino-tools-dev@googlegroups.com > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols > Sent: Wednesday, August 04, 2010 3:45 PM > To: Rhino Tools Dev > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > I am publishing the DomainEvents from my domain. These events are > subscribed to by 1 (or more report) services that update the db state > from those events. > @Udi - I could publish them one at a time, yes, but I'd rather the > whole batch fail since they represent a unit of work from my > domain...I don't want some messages to succeed and others to fail > leaving the db in an odd state. > > On Aug 4, 5:39 am, Ayende Rahien <aye...@ayende.com> wrote: > > What is the scenario in which you would want to publish a message batch? > > And publishing doesn't use the owners, it uses the subscriptions list. > > I think that I had the wrong idea in mind about what we are talking about, > > yes, for publish, that would make sense, but I still want to know what > your > > scenario is. > > > On Wed, Aug 4, 2010 at 3:33 PM, Mike Nichols > <nichols.mik...@gmail.com>wrote: > > > > Isn't that the difference between Publish and Send though? > > > 'Publishing' an event in my mind doesn't carry any assumption about > > > who is dealing with its payload. 'Sending' on the other hand does > > > carry those transactional assumptions. > > > > On Aug 4, 5:26 am, Ayende Rahien <aye...@ayende.com> wrote: > > > > Mike, > > > > The problem is that there is a difference between the expectations. > > > > You should be aware which messages goes to which endpoints. > > > > By splitting a batch you may be violating the assumption of the user > that > > > > they are sending one unit of work to the server. > > > > > I don't have an issue with throwing if you are sending a batch to > mixed > > > > endpoints, though. > > > > > On Wed, Aug 4, 2010 at 3:22 PM, Mike Nichols <nichols.mik...@gmail.com > > > >wrote: > > > > > > Yes, but each endpoint _will_ treat the batch as a single unit for > the > > > > > batch though only in its own context. Otherwise the publisher is > > > required to > > > > > have some knowledge of its subscribers right? To be clear (sorry if > I > > > am > > > > > thick), how do you handle this scenario: > > > > > 1. There are two messages in a batch > > > > > 2. Message1 is subscribed to by Endpoint1 > > > > > 3. Message2 is subscribed to by Endpoint2 > > > > > 4. You Publish(new[]{ message1,message2}); > > > > > > With the current codebase, only Endpoint1 will receive the batch of > > > > > messages...(it looks at 'messages[0]' to GetSubscriptions). That > > > doesn't > > > > > seem predictable. > > > > > > Another option is to have the publisher somehow split up the > messages > > > so > > > > > that they will be published to the correct endpoint. That seems to > > > turns > > > > > things upside down though. > > > > > > Other than feeding messages one by one is there some better > > > alternative? > > > > > > On Wed, Aug 4, 2010 at 12:45 AM, Ayende Rahien <aye...@ayende.com> > > > wrote: > > > > > >> Mike, > > > > >> Perf isn't what worries me. > > > > >> Message batches are treated as a single transactional unit. > > > > >> If you send them to different endpoints, you break that assumption. > > > > > >> On Wed, Aug 4, 2010 at 6:29 AM, Mike Nichols < > > > nichols.mik...@gmail.com>wrote: > > > > > >>> I have (clumsily) fixing an issue in rsb where it currently simply > > > > >>> looks at the first message in batch being Published for its > > > > >>> subscription info. > > > > >>> I am publishing a number of messages that may or may not be > > > subscribed > > > > >>> to (these are events from a store) and which are subscribed to at > > > > >>> different endpoints. Under the current setup (PublishInternal), if > a > > > > >>> message doesn't happen to be subscribed to in the same endpoint > the > > > > >>> first message in the batch it will not get sent to get handled. > > > > > >>> The initial fix is to GetSubscriptions for each message in the > batch > > > > >>> to make sure all subscriptions have been harvested that are > > > > >>> interested. > > > > > >>> My question is about the performance of something like this on a > > > > >>> massive batch of messages where I am iterating on the collection > > > > >>> (please see my pull request). > > > > > >>> This scenario doesn't seem far fetched to me, but if there is a > > > better > > > > >>> way of implementing it I'd like to hear it. > > > > > >>> -- > > > > >>> You received this message because you are subscribed to the Google > > > Groups > > > > >>> "Rhino Tools Dev" group. > > > > >>> To post to this group, send email to > > > rhino-tools-...@googlegroups.com. > > > > >>> To unsubscribe from this group, send email to > > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g > ooglegroups.com> > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252Bunsubscr > i...@googlegroups.com> > > > > > >>> . > > > > >>> For more options, visit this group at > > > > >>>http://groups.google.com/group/rhino-tools-dev?hl=en. > > > > > >> -- > > > > >> You received this message because you are subscribed to the Google > > > Groups > > > > >> "Rhino Tools Dev" group. > > > > >> To post to this group, send email to > rhino-tools-dev@googlegroups.com > > > . > > > > >> To unsubscribe from this group, send email to > > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g > ooglegroups.com> > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252Bunsubscr > i...@googlegroups.com> > > > > > >> . > > > > >> For more options, visit this group at > > > > >>http://groups.google.com/group/rhino-tools-dev?hl=en. > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Rhino Tools Dev" group. > > > > > To post to this group, send email to > rhino-tools-...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g > ooglegroups.com> > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252Bunsubscr > i...@googlegroups.com> > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/rhino-tools-dev?hl=en. > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Rhino Tools Dev" group. > > > To post to this group, send email to rhino-tools-...@googlegroups.com. > > > To unsubscribe from this group, send email to > > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g > ooglegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/rhino-tools-dev?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to rhino-tools-...@googlegroups.com. > To unsubscribe from this group, send email to > rhino-tools-dev+unsubscr...@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-...@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-...@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
