0

I'm writing service layer for DDD app.
Services are exposed through JSON-RPC over WSS.
I'm not sure how to respond to redundant calls to service.

Some facts about the system:

  1. All requests must be completed within specific time or timeout exception occurs.
  2. If system is under heavy load it may decide to discard request (visible as timeout).
  3. If system is under heavy load some messages may expire in the queue (visible as timeout).
  4. Even if request reaches it's destination ACK may not reach user in time (visible as timeout).
  5. End user has right to re-invoke method if ACK didn't arrive in time.

No guarantees on request completion are given. Thus the need for idempotency.

Problem arises if we consider [4]+[5] implications:

  • User invokes method setFoo(Bar).
    • Entity was created but ACK didn't make it on time.
  • User receives timeout and assumes that he should try again, so he re-invokes setFoo(Bar).
  • Entity already exists -> hmm...

Question is: Should user get ACK or Error(I've already done that mate...)?

Grzesiek
  • 120
  • 8

1 Answers1

3

An idempotent operation should have the same behaviour when it is called multiple times. This suggests that the return value should be the same as well, so in the scenario you are describing above, the user should get ACK.

Consider the alternative; if you return an error to the user, then how should the user respond? What "error handling" is appropriate?

You can make an argument for a response of ACK(I've already done that mate...) but the part in brackets should be a purely optional informative field, not something that affects how the user processes the response.

Richard Neish
  • 8,414
  • 4
  • 39
  • 69
  • Arguably one could say that even if the method returns Error it does not change the state of the application(server side) and does not create side effects. Therefore we could still say it's Idempotent. – Grzesiek Oct 02 '14 at 11:54
  • 1
    Idempotent from the server point of view, but not from the user. Do you want the action of calling the server to be idempotent as well? – Richard Neish Oct 02 '14 at 11:57
  • I like the idea of "metadata" in ACK. Perhaps all idempotency related errors(Exists etc.) should be attached as metadata. Thanks for that. – Grzesiek Oct 02 '14 at 12:04
  • Yes I do. I'm worried about a scenario where information is lost about the reason for success of operation. For example: _I want to add read permission to user X. After execution I've got ACK(Mr. Y already gave that permission to user X)_. Basically intent was satisfied but operation was not successful. This type of distinction makes sense for UI in many scenarios and it's difficult to achieve otherwise. – Grzesiek Oct 02 '14 at 12:12