Timeline for Prevent duplicate event handling
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 9, 2018 at 14:57 | vote | accept | Nick Williams | ||
| Dec 19, 2016 at 20:08 | history | tweeted | twitter.com/StackSoftEng/status/810939768561430530 | ||
| Dec 19, 2016 at 14:44 | comment | added | CheckRaise | Does your bus implementation support a "saga" type feature? docs.particular.net/nservicebus/sagas | |
| Dec 19, 2016 at 13:21 | comment | added | Derek Elkins left SE | @NickWilliams That article is somewhat annoying. It states exactly-once delivery is impossible and then provides two means of implementing it. I agree with one of the commenters that the author just slightly reinterpreted the term. What is relevant, though, is that in general exactly-once delivery requires coordination with the recipient. Taken to the end-to-end conclusion, this means the customer. In theory Message-IDs would at least allow exactly-once delivery to the customer's email server, in practice email specs seem to be a series of broken promises. | |
| Dec 19, 2016 at 3:39 | answer | added | VoiceOfUnreason | timeline score: 6 | |
| Dec 18, 2016 at 22:33 | comment | added | Nick Williams | I get that I can determine that the transaction failed. But if the event was redelivered, the event handler would not know that this event already created an email. bit.ly/1xiuGAb | |
| Dec 18, 2016 at 22:27 | comment | added | Nick Williams | Sorry Kevin I am not following, how does it do that? You could begin a transaction, persist the id (insert/update a table), send the email, attempt to commit the transaction but the commit fails. For instance if the application server lost connection the database server. Given persisting the last handled id is a single statement it is already atomic, consistant and durable. The message bus would deliver events serially so the action is isolated. I think I might be misunderstanding your solution? | |
| Dec 18, 2016 at 22:17 | comment | added | Kevin Krumwiede | It will allow you to detect the failure to persist the event ID and avoid sending multiple emails. | |
| Dec 18, 2016 at 21:38 | comment | added | Nick Williams | How can ACID databases help here? What does the transaction commit? There is no way to rollback sending the email if the dB transaction is not committed. | |
| Dec 18, 2016 at 21:16 | comment | added | Kevin Krumwiede | Something like you describe is already done for you by ACID databases. | |
| Dec 18, 2016 at 18:48 | history | asked | Nick Williams | CC BY-SA 3.0 |