Using Atomic Transactions to Power an Idempotent API | Hacker News Reader

Using Atomic Transactions to Power an Idempotent API

brandur.org

47 pointsmikecarlton8 comments

Is it common for people to solve concurrency problems in the database by using serializable txn isolation? I'm genuinely curious. I realize you should always measure these things for your specific use case, but I've always thought that was a non-starter from a performance perspective. What are the real tradeoffs these days with it?

Check out the TPC benchmark: http://www.tpc.org/information/benchmarks.asp

I fail to understand the need to re-use terms from other fields in a completely twisted way. For those like me wondering what an "idempotent API" is: making multiple identical requests has the same effect as making a single request[1].

Then you have other people using the exact same term to refer to a (seemingly) totally different concept: An idempotent operation completes no more than one time[2].

Maybe I'm thicker than the average web developer, but I think that there must be a simpler way to explain this concept. Specially without reusing a term that, formally, means something completely different[3] than any of the possible interpretations that I have come up with so far.

[1] http://www.restapitutorial.com/lessons/idempotency.html [2] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_In... [3] https://en.wikipedia.org/wiki/Idempotence

I teach a lot of pretty middling software developers about idempotence when discussing configuration management tools, and it seems pretty graspable. Idempotence is `f(f(x)) = f(x)` and nothing but. This is your #1.

Upon a second read, what AWS is saying is "if you pass a token and this has already been done with that token, return the original result." That token is just setting part of `x`.

By your definition, how can a REST API be idempotent? Say that GET(user) = john so, what I'm interpreting is that: GET( GET(user) ) = GET(john) = john. That doesn't seem valid to me.

GET requests are a bad example because usually GET(x) will always return the same thing, unless x was updated in some fashion

Let's work with the classic TODO app example. Say the user adds a TODO item, and makes a POST request to the server to store it. If the user POSTs their TODO, but due to your front-end being overly-eager to hear back from the server, it sends the request twice because the first one took too long to respond.

This should not create two identical TODO items, but instead only create one. This is the concept of idempotence; performing the same operation n (n > 0) times should be the same as performing it once.

It's slightly notationally inaccurate to say f(f(x)) is what the client is performing in this case, it's more like f(x) * f(x), but these details surely are unimportant.

The AWS example is really the same thing (making multiple identical requests is the same as one request), just explained very poorly. Further down:

> If you launch your instance using run-instances (AWS CLI), ec2-run-instances (Amazon EC2 CLI), or RunInstances, you can optionally provide a client token to ensure that the request is idempotent. If you repeat a request, the same response is returned for each repeated request. The only information that might vary in the response is the state of the instance.

These are also both the same as the original mathematical definition. You're right about term overloading in the general case, but this isn't really an example of that.

Your point is valid, but just wait till you encounter "isomorphic javascript". Web development uses formal terms in a more "feels like" way than academic literature, sadly.

Reply on news.ycombinator.com