ianG wrote: > I'm wrestling with a protocol error condition where an action has been > done already, the requester innocently asks for it to be done, and is > told that it is already done. Idempotency, in a nutshell. > > The problem with "already done" in an idempotent sense is that it is > both an error and a success. > Not quite.
By definition, idempotent means that if you apply the transaction a 2nd time, you should get the same results as the first time. For example, set x=2 is idempotent x=x+1 is not "Already done" is not a legitimate nor relevant, response. The more common response is simply to return the result of the transaction. For example, for a key-value store: read(key) -> 5 read(key) -> 5 write(key,10) -> 10 read(key) -> 10 write(key,10) -> 10 (not, "already done") Now, if you're doing something like an HTTP PUT, and you repeat a transaction, the first time you might get a "201 Created" response, subsequent times you might get "200 OK." So, slightly different response, but same result - specified object is in the specified location. So, for your situation: > I'm currently tracing an instance of "create account" that is wending > its way up through layers of results, and it's getting a bit confused. The HTTP PUT model might be appropriate. The first time, through, the account is either created or not (returning either a "fail" or a "created" message). Subsequent attempts to create the account simply return "ok." This assumes that you're passing the same configuration data each time. CREATEACCOUNT(JohnDoe) should have the same account, whether transmitted once, twice, or n times - after the transaction, there's an account named JohnDoe. (Mind you this doesn't address the case where you're trying to create a new account where one already exists - the "name already in use" case.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
