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.
