Comments on: How Should An Exactly Once SOA Reliable Messaging System Be Designed? http://www.goland.org/exactlyonce/ Technology, Politics, Food, Finance, etc. Mon, 23 Jan 2012 17:37:17 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Administrator http://www.goland.org/exactlyonce/comment-page-1/#comment-5583 Administrator Sat, 15 Oct 2005 16:56:17 +0000 #comment-5583 Olli, unfortunately the scenario you describe is unavoidable if a system is allowed to forget IDs. But as I describe in the article being able to forget IDs is a requirement (especially for synchronously reliable systems where the actual response has to be cached) because of space considerations. The key then is in designing a particular service to make sure that the time windows are 'reasonable' given the expected usage. But yes, there will always be failure cases. Without infinite memory they are unavoidable. Olli, unfortunately the scenario you describe is unavoidable if a system is allowed to forget IDs. But as I describe in the article being able to forget IDs is a requirement (especially for synchronously reliable systems where the actual response has to be cached) because of space considerations.

The key then is in designing a particular service to make sure that the time windows are ‘reasonable’ given the expected usage. But yes, there will always be failure cases. Without infinite memory they are unavoidable.

]]> By: Olli http://www.goland.org/exactlyonce/comment-page-1/#comment-5581 Olli Sat, 15 Oct 2005 11:24:21 +0000 #comment-5581 Hi, what happens if Sender sends request with timestamp Receiver processes request and sends acknowledgement Acknowledgement get's lost because of network break Receiver repeats request with first-instance timestamp but the network is fixed only after the window, so the request will be rejected because of the first-instance timestamp is too old Now the sender does not know if the request is processed and it has no way to repeat because if he would use a new ID with a new first-instance timestamp this can (and in this scenario would) lead to a double processed request. Hi,

what happens if

Sender sends request with timestamp
Receiver processes request and sends acknowledgement
Acknowledgement get’s lost because of network break
Receiver repeats request with first-instance timestamp but the network is fixed only after the window, so the request will be rejected because of the first-instance timestamp is too old
Now the sender does not know if the request is processed and it has no way to repeat because if he would use a new ID with a new first-instance timestamp this can (and in this scenario would) lead to a double processed request.

]]>