No, it means if the transaction is applied the task will be queued. The original statement is saying the datastore could commit your transaction, but the connection between the front-end and the database node times out for some reason. Transaction is committed bu the app might not know.
As for tasks, they should always be idempotent, occasionally, for many different reasons, a task will run multiple times. On Tue, Jul 12, 2011 at 11:23, Joshua Smith <joshuaesm...@charter.net> wrote: > 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. > -- 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.
