Hi Pol, Answering your first concern in numbers:
1) I think there is a misunderstanding on getting an exception for a failure. Because a transaction will succeed or fail. FYI we are aware this is unclear in the docs and we are working on it. But as I said before if you could live with 1 in a million transaction to not know fore sure the outcome (succeeded or failed) you wont need to make your process idempotent. 2) There is no fake-real-transaction, for example, one of the other uncommon exception that someone could get in the commit() would be Timeout exception. With any distributed system, unless you are willing to wait for an answer forever, there is always the possibility that you will get a timeout before the remote system responds with the result of the operation you requested (this is true in all databases), what GAE warranty is that the transaction either commits successfully or it does not, so if you implement some retry logic in transactions, having it idempotent will warranty you don't do the transaction twice. For the counter example, to make something idempotent you need a way to distinguish each time the counter gets incremented, it would depend on the logic of the application. its really hard to make it idempotent by itself. lets say part of a transaction would be incrementing a counter, if the process of incrementing is unique to users and a user can only incremented once, you could maintain another kind that gets set inside the transaction that stores the user that incremented the counter. then your logic inside the transaction will first check if the user already incremented the counter by making a get to the kind that keeps track of that (we can assure that if a user appears here the transaction was committed because a transaction either fails or not) if he did not, you go ahead and process the logic again, else do nothing (it already did it). This will make sure the transaction is not redone if you retry it after getting an exception where the outcome was unknown. But as I said before, this exceptions are uncommon and it would be good to know what are you doing inside the transaction that is causing those transactions. Timeout exception could be related to master slaves issues (in a M/S app) this could go away by migrating to High replication datastore. Hope this helps clarifies some points. Best, Jose -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/klKa70GFvwAJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
