from Hacker News

Ask HN: Distributed transactions from mobile app to web server

by tobinharris on 5/7/15, 4:39 PM with 7 comments

    1. A mobile app places a booking on the server over a HTTP POST
    2. Server completes transaction, sends 200 response back to app.
    3. Network blip. App didn't receive the response. 
       Server thinks everything went peachy. 
    4. So app shows network error. 
    5. Big fail because customer thinks booking failed. 
       Server thinks it went great. 
       Death and destruction ensues... :)

• by tobinharris on 5/7/15, 5:00 PM

  P.S - my current favourite solution would be a 2 phase commit when the mobile client does 2nd API call to commit the booking. Server rolls back the booking if no commit received within N seconds/minutes.

• by amarraja on 5/8/15, 7:10 AM

  Not sure if this is a recommended approach, but I did something similar recently.

  I create a guid on the client, and send this with the request. If I get a connection error or no response, I re-query with my client side id to see if the transaction succeeded.

  I'm sure there are downsides to this, however for now it's simple and seems to be working well.

• by justonce on 5/7/15, 6:15 PM

  You can't protect against this. Any confirmation messages are subject to the same problem. Look up the FLP paper for proof.

  This is really a user interface problem; your user needs to think of a transaction during a network outage as being in an "unknown" state rather than a "succeeded" or "failed" state.

• by PublicEnemy111 on 5/7/15, 6:29 PM

  Could you theoretically wait to commit database transactions until after the client has sent acknowledgement of the response?