How can I make sure I have received event (A) from an aggregate and event (B) from another aggregate before invoking a method from a third aggregate in the event handler? For example, I need productPaid event and productInStock event to buy a product?
Maybe you can do a query in the handler to some aggregate to check if the other event already happened.
Or, you need a "process manager" instead of an "event handler".
You need a state that is shared by the two event handlers, something that when you receive an event allows you to record that it happened (some storage), and when you handle an event you can check if you already received the other one.
You can think to a process manager like an aggregate that receives events instead of commands (it cannot reject them!)
Related
I am trying to make sense of which one should be called before and which one later between wl_display_dispatch and wl_display_roundtrip. I have seen both order so wondering which one is correct.
1st order:
wl_display_get_registry(display); wl_registry_add_listener() // this call is just informational
wl_display_dispatch();
wl_display_roundtrip();
what i think : wl_display_dispatch() will read and dispatch events from display fd, whatever is sent by server but in between server might be still processing requests and for brief time fd might be empty.
wl_display_dispatch returns assuming all events are dispatched. Then wl_display_roundtrip() is called and will block until server has processed all request and put then in event queue. So after this, event queue still has pending events, but there is no call to wl_display_dispatch(). How those pending events will be dispatched ? Is that wl_display_dispatch() wait for server to process all events and then dispatch all events?
2nd order:
wl_display_get_registry(display); wl_registry_add_listener() // this call is just informational
wl_display_roundtrip();
wl_display_dispatch();
In this case, wl_display_roundtrip() wait for server to process all events and put them in event queue, So once this return we can assume all events sent from server are available in queue. Then wl_display_dispatch() is called which will dispatch all pending events.
Order 2nd looks correct and logical to me, as there is no chance of leftover pending events in queue. but I have seen Order 1st in may places including in weston client examples code so I am confused whats the correct order of calling.
It would be great if someone could clarify here.
Thanks in advance
2nd order is correct.
client can't do much without getting proxy(handle for global object). what i mean is client can send request by binding to the global object advertised by server so for this client has to block until all global object are bind in registry listener callback.
for example for client to create surface you need to bind wl_compositor interface then to shell interface to give role and then shm(for share memory) and so on.wl_display_dispatch cannot guaranty all the events are processed if your lucky it may dispatch all events too but cannot guarantee every-time. so you should use wl_display_roundtrip for registry at-least.
As to my understanding, in event sourcing, events are recorded. However that would also mean a state changed first happened and thereafter we record the event. For example, assuming:
A Client sends a command to a server to "Create user".
The server validates the command and creates user i.e. stores new
user in a database.
The server then logs/stores a Created User event. i.e event
sourcing.
Created User event is propagated to subscribers
In the scenario above, how do we handle scenarios where step (2) succeeded but step (3) failed due to say network failures, database offline etc? The whole system would be in an indeterminate state now that there was a new user created but the event was never logged. How do we mitigate these types of failures? Or are the steps that I've listed above not the way to do event sourcing?
Thanks!
This is not what happens exactly in Event sourcing, not even in plain CQRS.
In Event sourcing, after the command is validated, the domain events are generated by the source (the Aggregate in DDD) and then they are appended to the Event store in the first step. After that the subscribers (read models, projections, Sagas, external systems) receive and process the new domain events.
In CQRS, after the domain events are generated, they are applied to the Aggregate and then the Aggregate's state and the new events are persisted in the same local transaction, as the first step. Only after that the subscribers receive the events.
So you see? Your situation cannot happen: steps 2 and 3 are persisted atomically, they succeed or fail together.
I'm trying to wrap my head around Laravel's queued event listener vs jobs.
To me, it seems like that both are very similar:
Both implement the ShouldQueue interface (in the case of event listener, this is an option)
Both implement the handle() and failed() (optional) methods to perform their respective tasks.
Essentially, to me, both are queued items that can be run asynchronously.
What I am able to distinguish so far is that jobs have more "advanced" features/configurations like $timeout, $tries properties and you may also delay the 'trigger' of a job (courtesy of the Illuminate\Bus\Queueable trait).
There are more I'm sure, but I'm pointing out the one that pops out to me.
So, the question is, what's the actual difference between the two and more importantly, when do you favor one over the other?
Good question, I will begin by how laravel docs explains it
Events : Laravel's events provides a simple observer implementation, allowing you to subscribe and listen for various events that occur in your application. Events serve as a great way to decouple various aspects of your application, since a single event can have multiple listeners that do not depend on each other.
Where as
Jobs : Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.
Essentially both are pushing jobs on to queues and/or do some processing its asked to do, the main difference I would say is how they are called.
Events are on the lookout to be called where as Jobs are always explicitly called.
Power of Events is that we can register multiple listeners for a single event and the event helper will dispatch the event to all of its registered listeners without us calling them explicitly. where in case of Jobs we would have to call them each one explicitly.
In short if you have a scenario where an event would trigger multiple method calls event would help. If its a single method call Jobs are good.
Events Scenario: user signs up -> Send email, Dispatch complimentary swag, Create a subdomain for a user profile userxyz.site.com etc etc
Jobs Scenario: user signs up -> Send email.
In the exact context of the question: "Event" is a "Queued Event Listener". Every Laravel Event has a Listener bound to it (the event listener), then, when we queue that event (in the listener) it is magically a "Queued Event Listener"
Well, they are very similar, the eventlistener takes an event as a parameter in the handle method, jobs don't.
Events are good in situations where you want to decouple the triggering part from the action part. For instance when you have several modules in the project and you want one module to react on an event in another.
One limitation of events compared to jobs are job chaining. If you for instance trigger several events from a controller you can't be sure that the worker dispatches them in sequence and that the first is completed before the other is started.
In these (rare) situations I sometimes end up with (non queued) listeners that in turn dispatches (queued) jobs that do the actual work (chained or unchained).
I'm trying to use Backbone.Marionette, and I read the docs on github about wreqr.
So, whats the difference between Event Aggregator, Commands and Request/Response. And when to use one or another?
They bascially all use messaging, and their difference is mainly semantic:
event aggregator: send a message when something happens. Code somewhere else might be listening for that message, but maybe not
request/response: have code send a request, and it will expect a response (e.g. send me refreshed data)
commands: code in one place commands code somewhere else to carry out an action. There usually isn't a return value.
I would like to add to David Sulc's answer.
Request/response is very different from event aggregator and commands. It is used for cases where one part your code requests something from another part of the code. A response would always be expected. Now lets see how event aggregator and commands are different.
Marionette's Event Aggregator allows you to implement publish-subscribe behaviour. Using the 'on' method you can subscribe to an event and bind an event to any object. You cannot implement this binding behaviour using commands. Also you can have multiple objects listening to any particular event. There may also be a case where no object is bound to or listening to any event.
Commands are specifically meant for performing some action in some other part of the code. There can only be 1 handler for a particular command, unlike events where you can have multiple listeners.
So to summarize, the use cases for each would be:
1) Request/Response: When you need some response from another part of the code.
2) Event Aggregator: When you want to bind objects to events
3) Commands: You just want some other part of your code to perform a task.
I found an interesting questions regarding the events in action script: is the event buffered and ordered?
Ie) In a swfloader example, I setup a timer(1 sec) to run a function, in the function I setup a listener to event INIT of the loaded swf. It depends on the network condition that whether the timer handler or the INIT event will be first executed. Imagine a case that the INIT event fired first but the handler to handle the INIT event be setup later, will the handler be invoked?
Another question, if the loaded swf fired several events very fast, will the events be kept ordered as the fire sequence?
First Question: No, if INIT event is fired first and there is no handler for that Event then that event will be lost. So the best way is to setup all the listeners first then start any loading operation.Second Question: Yes, all the events fired will be handled in the same order as they're fired.
i just wanted to add to that you can change the order in the optional params
by default first in is the first served but if you change you priorities around that can change
obj.addEventListener(type,listener,useCapture,priority,useWeakRefrence);
the higher the number is the higher it is in priority. so if i would add these events:
obj.addEventListener(type,listener1,useCapture,1,useWeakRefrence);
obj.addEventListener(type,listener2,useCapture,2,useWeakRefrence);
the second event would happen before the first one. p.s after you create the event there is no way to change the order without removing the event and adding it back in.