Or, later on that page, where it says: Transactional tasks are useful because they allow you to combine non-datastore actions to a transaction that depend on the transaction succeeding (such as sending an email to confirm a purchase).
Does the caveat mean that in your example, the purchase could happen but the email never gets sent? This smells like a serious bug that you have decided to document, rather than fix. On Jul 12, 2011, at 11:56 AM, Joshua Smith wrote: > 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. > -- 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.
