title: GAE transaction failure and idempotency
body: <p>The Google App Engine documentation contains this paragraph:</p>
  
  <blockquote>
    <p>Note: If your application receives an exception when committing a
    transaction, it does not always mean that the transaction failed. You
    can receive DatastoreTimeoutException,
    ConcurrentModificationException, or DatastoreFailureException
    exceptions in cases where transactions have been committed and
    eventually will be applied successfully. Whenever possible, make your
    Datastore transactions idempotent so that if you repeat a transaction,
    the end result will be the same.</p>
  </blockquote>
  
  <p>Wait, what? It seems like there's a very important class of transactions that just simply cannot be made idempotent because they depend on current datastore state.  For example, a simple counter, as in a like button.  The transaction needs to read the current count, increment it, and write out the count again.  If the transaction appears to "fail" but doesn't REALLY fail, and there's no way for me to tell that on the client side, then I need to try again, which will result in one click generating two "likes." Surely there is some way to prevent this with GAE?</p>
  
  <p>Edit:</p>
  
  <p>it seems that this is problem inherent in distributed systems, as per non other than Guido van Rossum -- see this link:</p>
  
  <p><a href="https://stackoverflow.com/questions/13740724/app-engine-datastore-transaction-exception">app engine datastore transaction exception</a></p>
  
  <p>So it looks like designing idempotent transactions is pretty much a must if you want a high degree of reliability.</p>
  
  <p>I was wondering if it was possible to implement a global system across a whole app for ensuring idempotency.  The key would be to maintain a transaction log in the datastore.  The client would generated a GUID, and then include that GUID with the request (the same GUID would be re-sent on retries for the same request).  On the server, at the start of each transaction, it would look in the datastore for a record in the Transactions entity group with that ID.  If it found it, then this is a repeated transaction, so it would return without doing anything.  </p>
  
  <p>Of course this would require enabling cross-group transactions, or having a separate transaction log as a child of each entity group.  Also there would be a performance hit if failed entity key lookups are slow, because almost every transaction would include a failed lookup, because most GUIDs would be new.</p>
  
  <p>In terms of the additional $ cost in terms of additional datastore interactions, this would probably still be less than if I had to make every transaction idempotent, since that would require a lot of checking what's in the datastore in each level.</p>