Please help me find my misunderstanding.

I am writing an RPG on App Engine. Certain actions the player takes consume a certain stat. If the stat reaches zero the player can take no more actions. I started worrying about cheating players, though -- what if a player sent two actions very quickly, right next to each other? If the code that decrements the stat is not in a transaction, then the player has a chance of performing the action twice. So, I should wrap the code that decrements the stat in a transaction, right? So far, so good.

In GAE Python, though, we have this in the documentation:

Note: If your app receives an exception when submitting a transaction, it does notalways mean that the transaction failed. You can receive Timeout, TransactionFailedError, orInternalError exceptions in cases where transactions have been committed and eventually will be applied successfully. Whenever possible, make your Datastore transactions idempotent sothat if you repeat a transaction, the end result will be the same.

Whoops. That means that the function I was running that looks like this:

def decrement(player_key, value=5):player = Player.get(player_key)player.stat -= valueplayer.put()

Well, that's not gonna work because the thing isn't idempotent, right? If I put a retry loop around it (do I need to in Python? I've read that I don't need to on SO... but I can't find it in the docs) it might increment the value twice, right? Since my code can catch an exception but the datastore still committed the data... huh? How do I fix this? Is this a case where I need distributed transactions? Do I really?

First, Nick's answer is not correct. DHayes's transaction is not idempotent, so if it's run multiple times (ie. a retry when the first attempt was thought to have failed, when it didn't), then the value will have been decremented multiple times. Nick says that "the datastore checks if the entities have been modified since they were fetched", but that doesn't prevent the problem since the two transactions had separate fetches, and the second fetch was AFTER the first transaction completed.

To solve the problem, you can make the transaction idempotent by creating a "transaction Key" and recording that key in a new entity as part of the transaction. The second transaction can check for that transaction key, and if found, will do nothing. The transaction key can be deleted once you're satisfied that the transaction completed, or you give up retrying.

I'd like to know what "extremely rare" means for AppEngine (1-in-a-million, or 1-in-a-billion?), but my advice is that idempotent transactions is required for financial matters, but not for game scores, or even "lives" ;-)