Hi Jose, > 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.
Just to be sure, are you saying that for a timeout exception the transaction has actually been committed or not? In other words, should a Timeout exception be dealt with the same way a TransactionFailedError is? I observe Timeout exceptions now and then where there is too much contention on the same entity group. But I've only seen a TransactionFailedError once in 2 months. > 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. I'm using the HR datastore already, but I'm not surprised with the Timeouts as in my case there can sometimes, but rarely, be close to 10 transactions / seconds on the same entity group. > Hope this helps clarifies some points. Thanks much for your detailed answers indeed! - Pol -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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.
