Yeah, like the example of a transaction on the page with that caveat: http://code.google.com/appengine/docs/python/datastore/transactions.html
First it says, "Make sure your transactions are idempotent" and then it gives an example which isn't. I'm not sure it's possible to do the task in that example correctly if you cannot tell whether a transaction succeeded or failed when it throws an exception. I just tried sketching out a solution that stored a transaction ID in the model, but that won't work because there could be multiple writers. The whole thing seems rather intractable, and the idea that you cannot tell whether a transaction succeeded or failed violates the principle of least surprise for anyone who's ever used a database! Can some googlers weigh in, and explain how, for example, the example in the documentation could be implemented correctly? -Joshua On Jul 12, 2011, at 4:26 AM, Ice13ill wrote: > This is kinda awkward... I mean, don't we use these exceptions to > rollback and try again BECAUSE some operations are needed to be > executed correctly and ONCE ?. For example, to increment a simple > counter, to obtain unique successive values based on that counter. > I don't think redesigning the whole server-side architecture > (operations) is an option for bigger apps... > > > On Jul 10, 11:50 pm, Lyn Headley <lahea...@gmail.com> wrote: >> Hello, >> >> I recently discovered the following, and to me troubling, disclaimer >> on the transaction docs: >> >> Note: If your app receives an exception when submitting 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. >> >> Oops, I have designed an app which is not always idempotent, but >> instead depends on the assumption that certain tasks use datastore >> transactions that are applied exactly once (and are retried until they >> throw no exceptions). Do I need to go back to the drawing board and >> redesign my app for idempotence? How common are concurrency/datastore >> exceptions thrown from eventually successful transactions? > > -- > 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. > -- 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.
