Oleg Kalnichevski wrote:
Hi Tim,[snip]
See my comments in-line below
[snip]My challenge is that the bank processes each GET request, even if it has the same parameters as a previous request (yes, I know that GETs should be idempotent but I don't have a choice). I can't charge people twice. I want to retry the request, though, if I know that the bank hasn't received it (DNS failure, connection refused, connection timeout), but I CAN'T retry it if they MAY have received the request (e.g. response read timeout, 500 error, etc.).
The problem you are having should better be addressed at the applicationOleg is precisely correct here. The *only* way you can guarantee that you aren't duplicating requests is to address the problem at a higher level. Perhaps put a "transaction id" or "message id" on each "GET" request, and the server will detect duplicate requests.
level, not at the transport level.
Failing that, you would need to make sure that the two machines were connected to the same network hub, so that communications failures of any sort help guarantee that *both* machines stop communicating with the outside world, and thus the server would recognize the problem as well. And that is still not a guarantee.
You could let us know which bank is in question, so the rest of us know not to leave our money with them, since they seem to have missed an important lesson in CS about ACID transactions. For that matter, their investors probably want to know. OK, don't tell us, since it probably violates some agreement you signed with them, but I sure would love to know....
There are so many better solutions that come to mind for this kind of functionality, like JMS based solutions, which offer support functionality like guaranteed delivery. Of course, my company sells such a product, so I should stop now before I cross the line into advertisement.
-Eric.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
